I have a VS2010 solution with 2 projects in it - a .NET 4 program, and an installer for it. The Installer is just a simple Setup Project with a prerequisite - .NET Framework 4.
The problem is that I need the installer setup.exe to always run as Administrator otherwise the setup will fail under the UAC. (It does not prompt me for privilege elevation by default.)
I tried putting a setup.exe.manifest (shown below) alongside the setup.exe to force it to run as administrator, but unfortunately Windows ignores it, most likely because there is already another manifest file embedded within the setup.exe itself and it's set to asInvoker rather than requireAdministrator.
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
</asmv1:assembly>
I also tried adding a launch condition with the following properties:-
(name): Elevated
Condition: Privileged
Message: This installation requires elevated permissions to continue.
That doesn't do a thing either.
So can anyone please shed a light on how to solve this issue?
P.S. I know you can workaround this issue by changing the compatibility settings of the setup.exe, but this is a manual process and cannot be done via an automated build process (TFS). Also, providing a shortcut with compatibility setting is also weird, since no one provide a shortcut to a setup.exe in the same folder, not to mention that the shortcut needs to know the exact path of the setup.exe beforehand. (The setup package will be moved around.)
Edit: By the way, my problem is exactly the same as the one described here. But unfortunately, no solutions were found for that guy and the asker just resort to ask his clients to use Run As Administrator manually, which is what I'm trying to avoid.
As pointed out by Frank, the Visual Studio setup project's behavior is documented at Microsoft's web site:
Visual Studio Installer Deployment
In other words, the setup.exe produced by VS008 and VS2010 will always be run without prompting for privilege elevation (unless you explicitly run it using the 'Run As Administrator' context menu option). It in turns will run each prerequisite component as well as the main MSI installer as separate processes and prompts for privilege elevation for any of them that needs it. This means that there may be multiple prompts for elevations.
However, for some reasons this does not always work. In my case, the elevation prompt for the .NET Framework prerequisite does not come up at all when I run setup.exe. But if I run the prerequisite installer directly, the prompt will come up. This means that the problem lies not with the prerequisite component, but with either setup.exe or with Windows itself.
The solution (or workaround)? According to Microsoft in the link above, we can force setup.exe to launch each prerequisite component and the main MSI to run with elevation prompts. To do this, we need to manually edit the setup project file (.vdproj) and change the following RequiresElevation value to TRUE, as shown below:
"MsiBootstrapper"
{
"LangId" = "3:1033"
"RequiresElevation" = "11:TRUE"
}
This is not the ideal solution, but it is close enough to my original requirement, so I'm satisfied with this solution.
If you want to Run MSI in admin mode here is the way,
1) Open your Setup Project, View->Launch Conditions.
2) Right click on Launch Conditions, and add a new Condition in your Launch Conditions.
3) Right click the Condition, choose Properties Window.
4) Set Condition to
AdminUser
.
5) Build and install.
I think that your problem is to do with the name of the installer. This link
How do I avoid UAC when my EXE file name contains the word "update"?
says that if the name has Update or Setup in it, then UAC will kick in.
Can you rename your installer to something else?
Related
I have built a windows service in DotNet Core that is installed with the Peter Kottas WindowsServer nuget (https://github.com/PeterKottas/DotNetCore.WindowsService). In order to install the service you have to publish the code, deploy it wherever, run cmd prompt with administrator rights, move directory to the deployed code and execute the following line: "MyService action:install"
<CustomAction Id="CallCmd" Value="[SystemFolder]cmd.exe" Directory="MYSERVICE" />
<CustomAction Id="MoveDirectory" Directory="MYSERVICE" ExeCommand="cd C:\Program Files (x86)\MYCOMPANY\MYSERVICE"/>
<CustomAction Id="CA_InstallMyService" Directory="MYSERVICE" ExeCommand="MyService action:install" />
<InstallExecuteSequence>
<Custom Action="CallCmd" After="PublishProduct" />
<Custom Action="MoveDirectory" After="CallCmd" />
<Custom Action="CA_InstallMyService" After="MoveDirectory" />
</InstallExecuteSequence>
Looking in Orca it appears to be sitting in the correct order, as these instructions can't browse to the folder until it has been created.
However, on executing the MSI and after clicking "Install" it gets halfway through, fails and runs backwards through the installation process. (I've tried watching the "Program Files (x86)" directory and do not even see my directory folder structure stated in my Product.wxs being created.
A little digging around in the event viewer shows this error:
Error 1721. There is a problem with this Windows Installer package. A
program required for this install to complete could not be run.
Contact your support personnel or package vendor. Action:
MoveDirectory, location: C:\WINDOWS\SysWOW64\cmd.exe\, command: cd C:\Program Files (x86)\MYCOMPANY\MYSERVICE
This is not a good design paradigm considering Windows Installer (and WiX) has built-in support for installing services, as well as starting and stopping them so they can be replaced or uninstalled. That nuget might be an interesting service model, but the start, stop, and deployment isn't the recommended way to install a service using Windows Installer. There's simply no need to run code.
See WiX ServiceInstall and ServiceControl elements.
You must mark your CustomActions as Execute="Deferred"
The InstallExecuteSequence happens in two parts, the first is a planning phase where it figures out what it will be doing and the second part is running the plan script it just made in an elevated context.
If you plan some custom actions in the InstallExecuteSequence but do not mark them deferred, they will run during the planning part of the execute sequence which is before any of the files have been installed because the InstallFiles standard action requires elevation and that happens in the 2nd part of the sequence when it runs the planned script.
Generally you use this pattern when you need to run an elevated custom action that needs property values from your install. You schedule two custom actions, one deferred and one not, where the non-deferred action actually sets some special values to be used by the deferred action when it executes.
I haven't used the Directory attribute for CustomActions before so you may need to re-write some of these actions to get them to work, I'm not sure.
This other question's answer should help explain a bit how deferred custom actions get values at runtime from properties of the installer if you need to change the way your custom actions work.
WiX - commit more than one Property to deferred Custom Action
While I agree with the answer provided by PhilDW that the most ideal way to handle windows services is to use the functionality provided by WiX, the problem here is that DotNetCore is designed to be multi-platform and currently does not contain any of the .Net Standard assemblies for windows services, hence why I've used Peter Kottas's nuget package to implement the windows service. A way round this could be to use a docker container - however, this is out of scope for the current version, so here is how I over came this issue:
TLDR: I called the install command via CustomAction when the user exits the application. This requires Administration rights, so the appropriate flags have been set in the MSI and the MSI is always ran using a Bootstrapper (Burn) application to give these rights in a user friendly manour.
First, I created a custom action to fire the install command in a command prompt.
<CustomAction Id="CA_InstallService" Directory="INSTALLDIR" Return="ignore" ExeCommand="cmd /s /c "MyService action:install start-immediately:false"" />
I then created a new WiX UI element. It's WixUI_Mode is "FeatureTree" and I added an extra "DoAction" property to the exit dialog to call the customaction when the user clicks Finish.
<Publish Dialog="ExitDlg" Control="Finish" Event="DoAction" Value="CA_InstallService" Order="990"></Publish>
The installer requires admin rights to call this, so in the Product.wxs file set the "InstallPrivileges" attribute on the Package element to "elevated". Now if you call the msi via command prompt with admin privileges this will successfully call the "action:install".
OR you can create a bootstrapper project that references your wix installer and in the Bundle.wxs file on the "MsiPackage" set the "ForePerMachine" attribute to "yes".
See comments for some loosely related side notes from myself.
I got from my software vendor a batch file which compile some components together based on an wxs file (wix ?) with candle and light to create an outlook add-in installer.
Unfortunately, the msi setup file created only install for the current user.
Since I want to use the result on a terminal server and it should only be installed once by the administration, I think that I have to adapt the wxs file to allow the setup file to install for all users on the terminal server, right ?
I cannot find any hints on google or such, on how to adapt it.
Thanks for your help.
Change InstallScope of Package from perUser to perMachine as below
<Package InstallScope="perMachine" />
There will be other properties of course but this is the one important to you.
Also there can be other changes needed for changing installer from per user to per machine. For eg if there are registry keys you will probably need to change those from HKCU to HKLM.
I'm trying to package and deploy a wpf application. I used install shield and I have created the setup file. When I try running the setup file it keeps throwing this error code
1925: it needs admin privileges to run the setup.
How do I configure the setup file to be run by any user? Should I make any changes in the registry during the creation of setup file in install shield? Is there anyway to work around this problem?
Thanks
It sounds like you're trying to create a per-user installation. Since Windows Vista, this requires several steps, but was made simpler with Windows 7. I would check a verbose log in case it highlights any specific problems, and if not, follow this general advice:
If this is always a per-user installation, set General Information > Require Administrative Privileges to No and set the ALLUSERS property to empty.
If this is only conditionally per-user, leave them as Yes and 1 respectively, and use the MSIINSTALLPERUSER property with ALLUSERS=2 to select a per-user installation at run time. Note that this only works on Windows 7 (MSI 5.0) and later.
Ensure that your setup.exe, if you are using one, does not elevate. Set Required Execution Level to Invoker in the setup.exe tab of the Releases view.
If you are not using MSIINSTALLPERUSER, ensure that you are not installing any resources to any machine locations. This includes installation files to the ProgramFilesFolder, registry keys to HKEY_CLASSES_ROOT or HKEY_LOCAL_MACHINE, or other machine-level items such as Windows Services. Note that you may have to exclude services from MSIINSTALLPERUSER scenarios as well.
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
I have a problem which I guessed would be really simple to solve... but duh.
I'm deploying a .NET application with VS2010. I have a C# Windows Forms project and a Deployment Project. I need the installer to run with admin privileges because the app is installed for all users and an entry to the registry is made.
When starting the setup.exe I'm not prompted for privilege elevation. The installer will just start and suggest to install to Program Files (x86) which is good. After clicking next the installer runs and finished with a success message. Which is basically a lie because it did not successfully install. Instead it puts the apps exe directly to C:\.
How can I make the installer ask for admin privileges. Or do I have to rely on my customer to right click the setup and select "Run as Admin" which is very error prone?
Clarifications about my setup:
In the File System view of the setup project I added (among other things) "Primary Output from project01 (Active)" and "Build Outputs from project01 (Active) to "Application Folder". I also added a shortcut to "Primary Output" into "User's Programs Menu\CompanyName\ProgramName".
In the Registry View I added an entry to HKEY_CLASSES_ROOT because I need to register an url handler.
I also modified the setup's settings: I set InstallAllUsers to True because it is supposed to do so.
When I build and start the setup.exe by double clicking (or by selecting Install from the project's context menu) I always get the same result: The installer runs without asking for admin privileges, ask for an install location (which I leave at the default C:\Program Files(x86)\Company\ProgramName) and then procedes after clicking Next. As a result, the exe is put directly in C:\ and the shortcut created of course points into Nirvana.
If I run the setup.exe manually as Administrator things work fine. But this cannot seriously be the way to go.
So how can I tell the setup to always run as Admin?
I think this is a perfectly valid question, is a real problem, and has an actual explanation.
I recently ran across this problem. In my case, the cause is that the AlwaysInstallElevated policy was set on the computer through GPO. The policy was set to 1 in the per-machine policy and 0 in the per-user policy. These policies can be manually set to reproduce the effect it has on MSI installers
Using msexec /log install.log /i Deploy.msi, I had a setup log and there were strings in it like this:
MSI (s) (A4:8C) [13:00:42:885]: Ignoring disallowed property TARGETDIR
MSI (s) (A4:8C) [13:00:42:885]: Ignoring disallowed property VSDNETURLMSG
MSI (s) (A4:8C) [13:00:42:885]: Ignoring disallowed property VSDNETMSG
It seems that Visual Studio does not set the SecureCustomProperties in the MSI correctly and post processing of some sort is needed. I think that moving to WiX may be a better long term solution instead.
A blog post on MSDN is what I found that helped me find the root cause to this problem.
I've come across the same issue as you, and have found a good enough solution for it. So it might work for you too. The solution is documented here:
VS2010 Setup Project - Run As Administrator
I will re-iterate the solution briefly here. Basically, you need to manually edit the setup project file (.vdproj) and the following property to TRUE:
"MsiBootstrapper"
{
...
"RequiresElevation" = "11:TRUE"
}
When starting the setup.exe I'm not prompted for privilege elevation.
This is the normal behavior. The boostrapper doesn't need elevation.
Which is basically a lie because it did not successfully install.
Instead it puts the apps exe directly to C:.
So it did install your application, but in the wrong location. This is not related to elevation. In the File System editor in your setup project where did you add your application files? Did you add them in "Application Folder"?
How can I make the installer ask for admin privileges.
A MSI package installed for all users automatically prompts for elevation when clicking Install button. If it doesn't elevate automatically and installs in a per-machine location (like C:), the installation fails and nothing is copied on the target machine.