I tried today to install Flexcel 5 in my Delphi XE2 installation with the16.0.4.4504.48759 version installed.
But still installer complain and says version field is blank.
How do I pass this obstacle ??
The error message says: RAD Studio XE2 installed version is: and the minimum version for running ......
Could it be related to that I do instal from my unprivileged user account and log in as admin, instead of installing from admin account (which notoriously installs all bpl's etc. in the admins account.
Additional comment.
When starting the installer, it doesn't see the compiler at all and not checkboxes are marked soI have to select XE2 manually.
On the other hand, FlexcelVcl installer saw too many programs, but installed correctly.
And there was no difference in behaviour if I tried install as adminisstrator
Hi,
I wonder if it can be some issue in the delphi installation.
The steps the installer does are:
1)We look at the registry, to the key "App" at:
HKEY_CURRENT_USER\Software\Embarcadero\BDS\9.0
In my machine for example, App is:
C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\bin\bds.exe
2) We then look at the properties of bds.exe that is mentioned in the App key. For example, if I right click my C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\bin\bds.exe , look at Properties and details tab, I see:
File Version: 16.0.4504.48759
And this is the number we use. This should work both in an admin or non admin account, it shouldn't matter. We of course need read access to bds.exe for this account.
Can you verify the steps? Open regeditor.exe, look at what you have in the "App" key, and then right click in that file and look at the properties->details->File version.
Is the correct version there?
In any case I don't think this should matter much, if you have a correctly installed delphi and it is up to date. If that is the case, you can just press ignore in the dialog, and FlexCel should install correctly anyway.
Strange. In some way, the key was totally wrong.
Under my admin account I find the mentioned key.
But in my actual user account the key name is not Embarcadero, but BDS.
Seems like there still is something that is not changed in program since good old Borland days.
Side effect might be now that I loose all installation information done so far ??
Perhaps you should alternatively look for BDS as main key ??
Hi,
While we could add a check for bds alone, I don't think I've ever seen BDS alone as the main key, it should be Embarcadero\BDS
This is actually the way windows guidelines says entries under software should be made: <company name><product> where company here is embarcadero and the product bds.
While I don't remember exactly where it is mentioned, in all documents they always mention embarcadero\bds
For example:
(search for HKEY_CURRENT_USER in that file).
I also thought you might be using the -r switch to start delphi:
But as the article mentions, with -r you can change the "bds" part of the path, but embarcadero should always be there.
<quote>
Your new registry hive will be stored in the registry at HKCU\Software\Embarcadero\name\version
</quote>
We could support some customization of the root registry path in the future (specially for users using bds /r) but I am not sure if the extra complexity will just confuse users, who mostly install in embarcadero\bds
I find finally at right place in registry thecorrct link which is toward c:\bds\Embaradero\RAD Studio\9.0\bin\bds.exe
Version number of this file is the one you mention, 16.0.4504.48759 whichj also is shown by the compiler help.
Could you have hardcoded the path or is the installer using my admin accounts information? The info is not registered in the current_user key for my admin account as it looks like
the path is not hardcoded, as you could have installed delphi in any folder or drive.
We do look at the registry at a hardcoded place ("HKEY_CURRENT_USER\Software\Embarcadero\BDS\9.0"), because this is where it is documented it should be.
The thing is, as you can see form the registry path, this is "HKEY_CURRENT_USER", not HKEY_LOCAL_MACHINE or any other machine-dependent registry entry. Being saved at current_user, it has to be registered in the current user.
Install can't read HKEY_CURRENT_USER for the admin account, and neither should it. It reads the current_user for the account it is running from.
Just to make it clear, if you open regedit under the same account the setup.exe will run, do you see the registry entry in hkey_current_user?
How are you installing delphi? In the first post you mentioned:
"I do instal from my unprivileged user account and log in as admin, instead of installing from admin account (which notoriously installs all bpl's etc. in the admins account." Can you expand a little more on that? You should install both delphi and flexcel from the non admin account for this to work, never loggin in as admin. If you do parts as admin, then some keys will end up at the admin "HKEY_CURRENT_USER" and others at the unprivileged admin "HKEY_CURRENT_USER"
Adrian Gallero2013-01-26 11:45:08
I am logged in as the daily user with no admin rights.
But C-disk is blocked from installing software there, , so UAC pops up and force me to log in with an admin account to run the installer.
And I have seen from other cases that then install program do so the admin account hkey_current_user registry, not mine.
I might get admin rights, but only at work and only for one installation at a time. :-(
Argggh.
Since I installed RAD studio at root when i think about it I was not needing to tell UAC about the installation,
But, since the installer ofFlexcel is named Install.exe and also has this name inside so it is not possible to trick installer, I am forced to log in as my admin account, and there the needed App key was not registered,
By copying App from my daily user account to my admin account (not administrator),Ilured the installer to do the installation.
Then next problem popped up.
Under what registry keys di the installer regiser the keys used, Tget are now stored under the admin accounts registry it seems like :-(
Hi, the installer accesses always HKEY_CURRENT_USER
All keys read or written by the installer are inside HKCU\SOFTWARE\Embarcadero\BDS\9.0
On the keys written, this includes library path and known packages.
I am checking if I can make a setup version that doesn't need you to login as admin. But would this solve your problems? I mean, is delphi correctly installed in the nonadmin account, with the correct registry keys?
yes, it is,
I have two accounts, pk-acahristo-l\achristo_adm and Uio\achristo
The last one is the account I use for computing, and it contains the registry for Delphi, while the other account contain just part as leftover after first trying to set up Delphi inProgram files(32) an finally ended installing all compilers in C:\BDS
But, when being forced by the installer and UAC to log in as pk-achristo-l\achristo_adm, your installers put the registry keys in the achristo_adm account and place the bpl files somewhere that my achristo account don't see at all.
Same applies to the FlexcelVCL installer by the way,
A solution might be running manual install
I am not really sure it can be fully fixed, since the installer needs admin rights for some steps (like modifying the system path), so some parts would have to run elevated.
As said, I am checking if it is possible to do a fully non admin install, and if it is possible we will make it available soon. If not, as you said the options are a manual install, or giving the user temporary admin rights to run the FlexCel installer.
Ps: I don't know about the other tms installers, but FlexCel doesn't put any bpl (or any file actually) outside the folder where you selected to install it. So the issue in this case would only be registry keys. Opening FlexCel.groupproj from delphi and right-click install the packages should fix most of it. (you would still miss F1 help, but setting up that is more complex)
Problems comes from the d\fact that installer do not open up for installing program for everyone.
Default when option is not available that install is done only for the installer.
So adding the option should make the regitration correct.
The main issue is, that even when this is an "installer", it isn't a traditional installer in most ways. (For example, it won't write anything to program files, because you aren't installing any application).
But on the other hand, this "installer" has to do a lot of registration issues, modify the system path, register the components inside delphi, change the library path, register the help, etc. It actually has to do a lot of things, and we need to check that none of them require admin rights. What it doesn't do is to install any application, so "installing for all users" doesn't make much sense if for example delphi itself isn't installed for all users.
So, as said, I will have to look at it further, but I believe it is solvable.
For testing, setup up a laptop as a domain computer
Make a local admin account in addition to domain user names who has no admin rights.
Log on as domain user who should use TMS components
Start setup routine, and log in as local admin to be accepted as allowed to set up the component.
After installation check known packets for local admin account and user account.
Here all registry keys are entered under the local admin account, not in my user account where they should have been registered.
So problem, how to name the set up tool so UAC is not triggered at all.
Hi,
I've been looking for some time into this problem, and there isn't a clean solution. Setups in windows aren't really designed to install components. The things are:
1)This isn't related on how setup.exe is named, it is because it has a manifest requiring UAC.
2)The requirement for UAC is because we need to change the path, and to change the path we need administrator permissiosns. If we don't alter the path Delphi will complain about not finding the FlexCel packages when you start it.
3)Setups in windows can be "non admin" or "admin". But everything is designed so you use admin installs (starting from the point that the default installation folder is progam files, which needs UAC. The problem with admin installs is that they access the HKEY_CURRENTUSER from the admin user, not from the loged in user. The problem with non admin is that they just don't have enough permissions to do their job.
The solutions could be:
1) Make the setup not require UAC, but require UAC in the moment that we change the path. This is way more complex than it should be, and it would be making the installation more difficult for 99.9999% of the users, who have admin rights in their users. (and one of the reason they do so is because not ahving admin rights gives all this kind of problems).
2) Keep it as is, but provide another setup for non-admin installs. I am afraid this can become confusing and will generate more issues than what it solves.
3)Keep it as is and make non-admin users install manually. I think this is what we are going to end up doing. Truth is, we have tens of thousands of registered customers (and tens of people trying the trial everyday), and you are the only person ever who complained about non admin installs. (and we have people asking everyday about everything). So I given the really low percentage that seems to be installing in non admin scenarios, I don't really want to make it more difficult for the rest to install in order to fix a so rare issue. Installing manually for those cases is still possible anyway.
I have still to verify other possiblities to allow non admin install so nothing is decided yet, but as said, I don't think we will be doing anything that will make it harder for everybody.