I need to write an installer for some executables. The user might copy them wherever he wants but usually this is performed in C:\Program Files\MyProgram
If there's visual studio installed I also need to copy something to system32 (and that requires admin rights I suppose).
Does that make sense to support normal users and admin users? I mean: if I need to install something I always need admin rights, is this correct?
Supporting both can be tricky but it can be done by using RequestExecutionLevel highest and then checking if you actually are admin with the UserInfo plugin. You would then have to tell the user to force the installer to run as admin if they are not already when you detect VS.
A normal user cannot write to $programfiles so you have to default $instdir to $localappdata\Programs\Yourapp. You should also take a look at SetShellVarContext, it will help you with the HKCU vs HKLM issue...
Related
Is there any possibility where wix bootstrapper checks whether user has admin privileges so that admin-msi can be installed, if not a non admin-msi is installed.
basically how to provide install condition inside chain to check windows version and privilege property.
How to make major and minor upgrades for wix bootstrappers.
As far as I know, you do not let the Wix bootstrapper "check whether user has admin privileges", but you actually specify the admin rights for the Wix installer so it can perform the installation properly. You would do so by specifying the follow Package properties:
InstallPrivileges="elevated"
InstallScope="perMachine"
In terms of functionality, this means that a User Access Control window will appear asking the user to allow the Wix installer to proceed with the installation. If the user does not happen to have an administrator account (or an account with administrative rights, however you want to describe it), Windows would require the user to type a username and password of an account that does have administrative rights.
Have a look at the following StackOverflow answer.
Hope that helps you!
I am working on a project that has been using 2 VD projects to distribute admin and user versions of installations, and now I need to switch to WiX. It was a bit painful experience with lack of documentation and all, but I managed to make something of it.
However, there is still one problem: I want to make only one .msi which will allow user to choose whether he wants to install as admin or as user. If he chose user, I don't want to ask him for elevation (as he doesn't need it), also if he chose admin, I don't want the installation to crash but to ask for privileges.
My current solution crashes in admin mode if I set InstallPrivileges to limited because the user doesn't have the permission to install, and it prompts for elevation in user mode if I set it to elevated.
My opinion is that there is no way to fix this because of compatibility with MSI, but perhaps there is some way to change privileges from elevated to limited in install time that I'm missing.
In conclusion, I want to know these things:
Is it possible to change privileges at install time
If there is no way to do so, what is the best workaround for this problem (exporting 2 .msi files or something)
One solution is to build two separate installers and then launch them via a custom WiX bootstrapper (aka Burn). The bootstrapper would be in charge of displaying the UI and launching the appropriate .msi.
Or you could separate the "admin" features into a separate .msi and then use a custom bootstrapper to install both .msis if the user selects an admin install.
I implemented an installer for our product. Installer needs administrator privileges, so I used setup bootstrapper with a manifest file (as recommended here) to get these privileges on a Windows machines with UAC enabled. Installation and uninstall goes fine - the user is asked for permission and the installer does what it needs to do.
But if you run Control panel → Programs and Features and select "Change"* for installed program, an error occurs (custom, from installer LaunchConditions), telling that the installer needs administrative privileges. And I can't find any way to ask for permission in a such case - Windows simply runs the MSI file and doesn't know anything about required permissions.
Even more strange is the repair functionality - it asks for permission, but then fails to do some actions that were allowed during installation, using SetupBootstrapper.
I found a similar problem here:
But the proposed solutions are unacceptable in our case.
The only workaround for the change functionality now is to always use SetupBootstrapper and do not use the Programs and Features menu, but that is not very user-friendly and forces the user to keep the installer on his/her hard drive.
Has anybody better advise?
PS: I use WiX for creating the installer, so it would be great to hear about WiX solutions, but I'm pretty sure that it doesn't depend on the installer creation language, but only on MSI specifics.
What actions are failing? If they are actions that you added to the installation, make sure that such actions are defined with Impersonate="no" and Execute="deferred" (or "commit" or "rollback") and that they are sequenced somewhere between InstallInitialize and InstallFinalize.
I try to register dll (ActiveX) for non-admin user using MSI.
To create registry settings I have register the dll in admin mode, then exported the relevant registry entries and renamed all HKLM to HKCU.
When I install it for non-admin user all works fine. But when I use the same settings with admin user, there is a problem of discovering TypeLib.
What should be changed in the registry entries to work both for admin and non-admin user, when the registration done under HKCU?
Thank you
If your entries are really registered under HKCU, it will work. What MSI installer are you using? There should be a way to specify that it should install in user mode.
Are you letting the dll self-register or having the msi register the dll? it is best practice to have the MSI do it, but it's more of a pain. If you're having the .dll self-register you need to make sure that the dll registers in HKEY_CURRENT_USER and not HKEY_LOCAL_MACHINE, which ATL does by default.
If you built it in VS2008 with ATL, you'll want to add:
AtlSetPerUserRegistration(true);
to your DllRegisterServer and DllUnregisterServer.
Anyway, those are some things to look for. You can use Process Monitor and watch the Reg commands to see exactly what is happening; something somewhere is writing to HKLM.
My installer places a file into /Library/Application Support/AppName. As a final step of the install process in a custom installer plugin (Objective-C code) I check for a more recent version of that file. If it exists, I download it and then attempt to overwrite the one created by the installer. The issue is that I apparently don't have permission to overwrite. Shouldn't the installer plugin that is part of the installer have permission to overwrite that file since the user was prompted for an admin password already?
Any ideas on how I can write to the /Library/Application Support/AppName directory from my installer plugin?
I believe that Installer actually uses a privileged helper tool to do the installation. The Installer app itself doesn't get admin privileges, which is why your plug-in doesn't have admin privileges.
The Apple docs explain one way to handle a privileged installation, although the BetterAuthorizationSample code is the "best" way to do it.
Unfortunately, handling privileged operations is quite tricky and you should study and understand the sample code and the Authorization Services documentation before implementing anything.