I have two projects as mentioned below.
VSTO Project(Word Add-In)
Installer (.ism) project to create installer for above word add-in
Recently, I have made some changes in above both the projects to replace old brand name with new brand name.
After these changes, installer does not uninstall already installed add-in and instead it installs second instance of add-in(having different product name). Earlier, it was able to uninstall existing word add-in.
Please note that I have not changed Product Code and Upgrade Code in ism file.
Now, I want to make installer (created using Install Shield project) capable enough to uninstall existing word add-in (having old product name) if it exists.
The word Add-In is being used by our many clients and after re-branding we want them to re install Add-in. We don't want them to manually uninstall existing word add-in. So, we want to make changes in installer so that it auto detects existing add-in and uninstall it and then install new one.
I am new to the install shield and don't know what is the best and simple way to achieve this.
I am not familiar with the latest iterations of InstallShield, but at a minimum you can call vstoinstaller.exe to remove it at the start. It's usually in C:\Program Files (x86)\Common Files\microsoft shared\VSTO\10.0.
Related
I'm using Advanced Installer to try to create an installation package (single EXE setup file) for an MS Project VSTO add-in. I need the installation Type to be Per Machine but when I chose this option and run the setup.exe file, the Add-in will not load for any of the user's on the target machine. The only way I can get it to load is if I change the installation type to Per User, which I don't want.
I'm fairly certain the problem is related to the registry, because the setup.exe is not adding the proper registry keys under HKEY_LOCAL_MACHINE to load the add-in, even though I have it set up to do so:
What am I doing wrong?
There are other things that needs to be done except windows registry keys. For example, you need to specify whether you want to support per-user or per-computer installations.
The Deploy an Office solution by using Windows Installer article describes all the necessary steps for creating per-use and per-machine Office add-in installers. Make sure that you did everything in your installation package.
I created a Wix Installer for my Visual Studio 2017 project by using this Wix Toolset Visual Studio 2017 Extension from its original author Rob Mensching. The installer successfully installed the app but when I run the installer again to uninstall the app, the installer, as expected, first shows the option of either repairing or uninstalling the app.
When I choose Uninstall option it successfully runs indicating it's uninstalling and finally shows the Finish button, but when I go to my Windows 10 menu the app is still there and still works as usual - that clearly means it was not uninstalled.
I even re-started the computer to see if that makes any difference but the app is still there and working as usual. Question: What could be a cause of it happening - and what is the remedy?
Note: I'm using the latest version 3.11 of Wix
UPDATE
It's a VSTO add-in. Now it is working as follows: I manually uninstalled it from Windows' Add\Remove program and then installed it again using Wix/MSI. And then when I uninstalled again using Wix/MSI it successfully uninstalled it. Question: Why initially it was not uninstalling when using Wix/MSI?
Duplicates: You have probably installed the product several times (at least two) whilst working on the package. This happens all the time, particularly if you use an automatically generated product code and haven't set up a major upgrade construct yet or the upgrade guid is missing or worse yet you set it to auto-generate. Upgrade codes should remain stable for "families" of products. Essentially all related editions that you don't want to install side-by-side.
So with duplicated installations, the uninstall of the product only removes the latest installation, leaving the files in place since the reference count is not zero as there are other installations. The solution is to keep a stable upgrade guid and set up a major upgrade construct. Before that uninstall all stray copies.
Maybe try this procedure:
Windows Key + tap R
Type appwiz.cpl and press Enter
Look for duplicate copies of the product in the list and uninstall them.
Hidden Products: It is also possible that some copies could be hidden from the above list.
Find Product Code: You can list all installed product codes and the product name using approaches described here: How can I find the product GUID of an installed MSI setup?
Uninstall: Once you have the product code you can uninstall via method 3 here: Uninstalling an MSI file from the command line without using msiexec
More Advanced: Here are some further options to uninstall via scripts: WIX (remove all previous versions).
I am trying to create a new installer (using Wix) which will going to substitute the current one (InstallShield). Problem is many clients already have the application installed using the current installer. I need my new Wix installer to detect currently installed application perform the update or force the user to uninstall current application before running the new Wix installer.
I am new with creating installers. I need to know which GUIDs (and version numbers) must be the same for the system to know this is actually the same application just a new version. I didn't create the old InstallSheeld installer but I do have access to its code.
Thank you very much.
To uninstall the old InstallShield package, you should find out your old upgrade code and use that within your new WiX installer and do a major upgrade (which will ensure that the old package is uninstalled and removed). Check this Wix Upgrade document for doing the major upgrade.
Since we are on the topic, you can also make use of the Dark.exe to convert the current MSI into WiX source files.
Suppose that you have an installer (not a wix installer) that you downloaded from somewhere. How can you know UpgradeCode of that installer so that you can fill it in in the UpgradeCode section in the new installer that you prepare?
Can I learn it from registry somehow? So the question is basically, how to know the UpgradeCode of a program that is installed in the computer.
Actually my problem is that my product has been installed with another installer and I am now trying to move it to wix installer. However, I can't find upgrade code in previous installer and I want to find it from installed software.
Thanks.
As I posted to WiX users:
I've seen this done by having the upgrade get the uninstall string from the registry, where there should be a command you can use since it's not MSI-based. Whether you should call it in the UI sequence or the execute sequence or both depends on your requirements for silent installs, meaning that you'd need to do it silently in the execute sequence, and perhaps need to alter the uninstall command to make it silent.
The same general idea should work if that install has a standard uninstall shortcut you could get the command from. Either way, you're just using a CA to run an external program, or maybe a Util
CAQuietExec kind of thing.
Assuming it's a Windows Installer based installer ( WiX, InstallShield, et al ) you can edit it with ORCA and look at the Property table to see it's UpgradeCode. You may have to first extract it if it was packaged as a self extracting installer.
You can also query the MSI API or look in the registry (HKCR\Installer) for this information. If you go the registry route it's probably easiest to look at the Products/GUID/Sourcelist key and trace it back to a cached MSI and look at it in ORCA. Otherwise you have to learn how to join different datasets and convert Darwin transformed GUIDS back to their original GUID format.
Fire up PowerShell (run as admin) and run this command to get a list of installed products with product code:
Get-WmiObject Win32_Product | Format-Table Name, LocalPackage
You will get a list of all installed MSI products, and a weird looking path to the local cached MSI database. It normally looks something like this:
C:\Windows\Installer\235bbf8.msi
The 235bbf8.msi file name is random, and will be different for each installed product. It is a cached copy of the MSI file that you originally installed. It does not contain cab files (or at least it didn't in older versions of Windows).
You can open that file with the random name from Orca by chosing File -> Open and then pasting in the full path to the file open dialog, and then pressing open. Don't make any changes but check the upgrade code in the Property table. You can also use other MSI tools such as Installshield.
Note that the path C:\Windows\Installer is "super protected" and is not even visible in Windows Explorer before you enable the show hidden folders AND you disable the protect operating system files option. I still believe you can open the file directly if you paste the whole path into Orca - no need to go via Windows Explorer.
I've packaged my vb.net project with an installer project and installed it on my pc. Now, how can I make an update patch if I want to update my installed program? I'm using Microsoft Visual Studio 2010. I've tried to Google on this issue but instructions are unclear to me.
One way to do it is as follows:
If the installer package installs your application into the fixed location, i.e. when user can't select where to install, you can always have your update package go to that same location and replace your assemblies.
If the location is dynamic, your initial installation needs to leave some registry keys/values related to the location. Then your update package can get the location from the registry and replace the assemblies based on that data.