Here's what I'm looking to do:
I'd like to perform an application install on a remote machine; as a part of that process, before I install the new version, I want to check that machine's registry for a pre-existing version of the same application.
If that machine has an existing instance of the application already installed, I want to find the MSI used to install it, so I can backup the MSI and perform a 'rollback' if necessary. From what I understand, Windows creates a copy of these MSIs and places them in some temp folder with a random name somewhere so that it can use it for uninstalls.
How might I find this location?
(Also, suggestions on how to check the registry values cross-network would be appreciated.)
As far as I understand, you don't have to find the exact MSI package. In order to uninstall a product, it is enough to know its product code and run msiexec /x {PRODUCT-CODE-GUID-HERE}. And product codes can be found under Uninstall registry key (typically, SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall).
Related
I have an MSI & EXE installer that installs the excel plug-in. The user has option to download exe or msi to install the plug-in. The problem is my applicaiton shows a notification to user if new version of applicaiton is available and if user get new version I always returns the msi file because at that point I don't have any information that user has installed the plug-in through msi or .exe. If user install thorugh exe and install new version with msi the multipe instance installed on same machine. How I can avoid it?
Also, is there any way in C# to know the applicaiton is installed through msi or exe?
You should have two different UpgradeCodes - one for MSIs and one for EXEs. Then new version of MSI will replace MSI, EXE will replace EXE. Also don't forget to upgrade version number, or you will face same issue.
You can't upgrade EXE with MSI, they are treated by system as different products.
How to find the UpgradeCode of installed app
I'm trying to find a way to install a program to the AppData folder for each user on a computer. We have a computer that a group remotes into and each uses the program on that computer. Currently the application is installed normally in the program files. The reason we need individual installations is that we've updated the application to use AppLife Updater, and if someone runs the program while someone else is also running it, and it needs an update, the update will fail. So we'd like to have each user have their own installation that won't interfere with other users installations when updating.
I've found that you can install to LocalAppDataFolder instead of ProgramFilesFolder, but when you do that, you get several ICE errors (Specifically, ICE38 and ICE64). I found a web article that showed a version of a Wix installer that installs to the LocalAppDataFolder, but it also has ICE38 and ICE64 errors.
AppData Wix Installer code/article
My question is, has anyone made a Wix installer before that installs to the AppData folder that does not have these issues? Is there documentation on how to do this, other than the cited article? I have read the Rob Mensching blog article
How to create an uninstall shortcut (and pass all the ICE validation).
ICE64 documentation
ICE38 documentation
The problem occurs when a windows user profile is created after installing our tool with the MSI installer.
When starting the tool with the new user, Windows wants to start the .msi file again.
(When the installation was run from a network path, Windows is then unable to find the installer)
The installation only installes 5 files (exe, dlls, txt) and creates a link on all users desktop.
Questions:
What is the reason why windows wants to run the installer again?
Is this the default behavior?
How can I prevent windows from starting the installer again with new users?
If this occurs when you click the shortcut, perhaps the advertised shortcuts have been created by the installation program and it tries to install the feature on demand. The differences between the types of shortcurts are described here. If it is your installation program you can try using non-advertised shortcuts in project. If you are talking about third-party software you can try creating your own shortcut for the installed executable.
Note that this repair to add the missing something should occur just once per new user to restore the data. If it happens more than that it's something more serious.
Even if you modify the shortcut, there is still the issue that if this new user (or any user) does anything that triggers a repair the same thing will happen. Repair is available from right-clicking the MSI file, and maybe from Programs&Features too. You really should keep the MSI file available.
If it's an accident that you didn't intend then why not just fix it? Look at the event log MsiInstaller event log entry, that might help. Also, Visual Studio may have added something that it thinks you need, like an extra HKCU registry entry - I believe that's been reported as an issue. You may find something in Orca or even in the setup project's UI in the HKCU registry.
I have a product which uses WIX to install.
This is my install sequence:
<InstallExecuteSequence>
<RemoveExistingProducts Before="InstallInitialize" />
</InstallExecuteSequence>
Which as I understand, deletes the entire older version upon re-installation.
This is the behavior I want to preserve, but I also want to copy a specific file from
the older version.
How do I do it?
To do what you want from a deployment of a new MSI will be almost impossible because you cannot execute a custom action before RemoveExistingProducts that requires elevated privileges (This might work if you are not installing in a UAC controlled folder like prgram files - but I have never tried that).
One workaround is to modify the existing MSI by creating a bootstrapper (I have no idea if this works tho!)– see the answer to this question: How to execute Custom Action before RemoveExistingProducts with After="InstallValidate" in WiX
When I have written installers in the past, I have written a custom action that copies the files out to a temporary folder on uninstall (The uninstall for the previous version of the MSI gets called by the new MSI when you upgrade) and then just inspect and clear this folder out when the new MSI installs (The upgrade part). This approach does leave a lot of files hanging around if you just uninstall (not upgrade) but as I am only interested in configuration files – this actually works out quite well as if a customer returns I won't have lost all their configuration.
This of course does not fix your immediate problem as this will only start working after a version which backs up relevant files on uninstall is distributed – but it has worked well for me for the last 3 years.
HTH
I am iterating over the SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall in the registry, what I noticed is that there are some programs that are listed in brackets like: {E05E8183-866A-11D3-97DF-0000F8D8F2E9}, and it has all the information like version and displayName.
Other programs that are not in brackets like 4591AF53-0A6B-4BB9-A335-AFF02C8D5BCD does not have all the information.
Could someone explain why is there a difference and if there is any other way know the version of a software installed.
You could find out which version of a program installed using Windows MSI installer is installed by going to: HKEY_CLASSES_ROOT/Installer/Products and iterate that. The GUIDS that you see under that directory is generated by the MSI installer to identify products installed, so it can find them again for uninstall.