I am having trouble with my WiX installation in that I am registering a file extension but because you have to tie every component to a feature, I can't get the feature to install to "All Users"?
Specifically what is happening is I install the MSI under an admin account. The MSI is not located in a shared location that is accessible by all users. The extension appears to register for the other users however when other users click on the file (with the newly registered extension) to open it, it tries to look for the original MSI first to install a feature. If the MSI is found it will open the installed application like normal, otherwise it errors. For the admin account that installed the MSI, it does not ask to install the feature from the MSI (even if I delete the MSI before clicking on a file with that extension)
I have set the installlevel of all the features to "1" and set the TypicalDefault to "install" and InstallDefault to "local". The package is also set to install at the machine level.
Is there something else that needs to be set?
See if this helps: Troubleshooting unwanted self-repairs using the Event Viewer
Basically you need to understand why the repair is happening (which component key path ) and then remediate it. Alternatively you could wrap your MSI with a EXE (WiX Burn) and cache the MSI in a location that users can access if the repair is truly needed.
Related
I created an msi that that installs my application. Now i want to do an update the msi. I used
msiexec /fvomus "application.msi"
This showed no error. But when when i try to update an application in remote machine it shows the below error
The installation package couldn't be opened. Contact the Application
vendor to verify this is a valid Windows installer
I used the below command for remote installation
msiexec /fvomus "//server/c$/Program Files/path_to_my_application/1.msi"
Assuming you want to update a product you've installed from an MSI package:
msiexec /f... does not update anything. The /f means that it's a repair, and that means to check that the currently installed product is correct. If you're using WiX and you want to upgrade an installed product then the MajorUpgrade element is the simplest and most reliable approach.
That error message is too generic to provide a simple answer. It may be that the MSI file is already open in another app, or you don't have the privilege to access that file (IMO the most likely explanation).
We have a legacy software installation that we're trying to remove from our organisation. We have different versions and are trying to create a universal uninstaller for all versions. We've come across a particular release that doesn't seem to be able to be uninstalled via command line though. And it's proving difficult to create a workaround.
I've found the GUID of the application in the registry via
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
And the command I run is:
msiexec /x {080FDF44-6D15-4D2E-977E-74D5168198E7}
I get an application prompt asking me if I want to uninstall the product, so I click 'Yes'. And then it looks like it's starting but never actually does anything. So I dug round the registry and found another GUID in:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Userdata\S-1-5-18\Products\44FDF08051D6E2D479E7475D6118897E
If I run the same command as above with the different GUID, I get the application confirmation box asking for uninstall then after clicking OK, I get an error saying:
The installation package could not be opened. Verify the package exists and you can access it.......
I've been into C:\Windows\Installer into the folder with the above GUID and all that is in there is an icon and an *.mst file. In the root of C:\Windows\Installer, there is an *.msi called the same product in the details but with another version ID of:
8A2C4F93-4B31-4474-B9F2-2E51BF5D71A8
If I run the msiexec against that ID then I get a confirmation box again then another error which says
The action is only valid for products that are currently installed.
If I run the uninstaller, it uninstalls fine from the programs and features and uses the generated *.msi for the uninstalled (e.g. C:\Windows\Installer\241a6.msi and matches the product ID of 8A2C4F93-4B31-4474-B9F2-2E51BF5D71A8). This will change form machine to machine. Any other ideas on how to get this off in a neat and managed way?
You can't dredge the registry for ProductCode guids because they are obfuscated. If you don't really know the ProductCode, then look at ways of enumerating installed products. For example, the direct C++ way is MsiEnumerateProducts, and C# pinvoke equivalents, something like this:
MSI Interop using MSIEnumRelatedProducts and MSIGetProductInfo
Then you will get the actual ProductCode and can get other info with it.
If sometimes it doesn't work when you are absolutely sure of the ProductCode, then it was perhaps installed in a per user context that's different from the one you're running the program with.
Also, for MSI-installed products Windows doesn't use the uninstall string, it just uses the ProductCode directly. Again, registry dredging is not the right thing when there are actual APIs specifically to enumerate installed MSI products.
If an uninstall requires access to the original MSI that it was installed from, then there are at least two reasons:
The MSI has an unconditional ResolveSource action that forces it to ask for the oroginal MSI file.
The cached version of the MSI file has been removed from C:\windows\installer.
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.
I had a windows installer install a service I created. I tested on my dev machine rather than a test machine. The application files no longer exist and the service does not show up in the list of Windows Services under Admin Tools. I am trying to remove the entry from the Add/Remove programs. I set the installer up with a custom action of uninstalling the service when the uninstaller is run.
Even with manually copying the files to the expected location and manually adding the service in to the list of services, the uninstaller fails. I can't manage to remove it from the list of add remove programs. How can I remove it from the list?
All the entries shown in the Add/Remove Programs panel are found in the Registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall -- you'll find your in a subkey named with a GUID (e.g. "{123409-adsf-1234...}") if it was installed from an MSI (in which case you probably want to re-run the MSI to remove cleanly you really should use msiexec /x {GUID} to uninstall, or double-click the original MSI package and choose "Remove") or it could be any name if it was installed with another setup tool.
Perhaps this will help:
http://setupanddeployment.com/cleanup/installer-cleanup/
http://setupanddeployment.com/cleanup/installer-cleanup-update/
We are installing several web sites using msi's as part of continuos integration tests.
For each build we want to uninstall the old msi and install a new one.
Problem is we do not have the old msi after the build server has done a get latest and rebuilt the system.
Is there a way in which we can uninstall the msi without having access to the orginal msi?
Yes you can, if you know the product code. Just type
msiexec /x [ProductCode]
on the command line. Or you could do it through the Add/Remove programs applet.
If you want to find the physical file, Windows actually stores a copy of the msi when it runs it - you will find it somewhere in your %WINDOWS%\Installer folder, but it will have been given a random name so could be quite hard to find :)
Alternatively if you don't know the product code (which you should) then try searching for your app name under the HKEY_CURRENT_USER\Software\Microsoft\Installer and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData registry keys, you will find the product code there. (quick hint: you can also search for UninstallString values in the registry).