I use VSI 1.1 to deploy my vCrib application. Some times after copying a new exe to replace one that was installed by the .msi, it tries to reference the .msi file to revert the exe or something.
After the .msi installs the exe files, I want to be able to copy new ones to the client without it ever referencing the .msi again.
Thank you for any understanding you can give me about Visual Studio Installer 1.1 and upgrading my VB6 executables.
What I would like to do for an update is simply zip all the new exe files along with an SQL script and have the user download the zip, extract the files, over-writing the exesting exe's.
Currently I release a new full msi, have them uninstall their software (backing up some key stuff), install the new msi and then restore the couple files they backed up. It is a little barbaric.
In the past I have posted exe updates on the site and users did not have a problem updating them. I really don't understand why the exe tries to open the msi.
I am including a screenshot of what it does when I execute the new exe.
The three basic ways of servicing applications installed via user-initiated Windows Installer runs are to: uninstall then reinstall an entire new MSI package, do upgrade installs using a whole (new) MSI, or apply a patch file (MSP).
You might look at the Help for VSI 1.1's Project Properties dialog's Product Information tab. In particular focus on the Product Code and Upgrade Code fields:
Upgrade code
Use this field to establish the unique code assigned to all updates of this product. For example, suppose your installer package file is the first version (1.0) of your product named MyProduct, which has the product code {99} and the update code {14}.
Once upgrade code {14} has been assigned to MyProduct, you should use it for any upgrades to the product. For example, if you ship version 2.0 of MyProduct, you would give it a new product code (maybe {191}) and the same upgrade code ({14}).
Assigning the same upgrade code to all product versions this way gives the Microsoft® Windows® installer the information it requires to automatically uninstall an older version of a product when a new version is installed.
This can reduce the need for a bulky manual uninstall/reinstall new for each update to your product.
For files emplaced during an installation you can also mark each one that you don't want removed during uninstalls by setting the Property DoNotUninstall = True. Then if you must have users uninstall/reinstall they don't have to fiddle with data that must survive across software updates intact due to changes since initial installation (per-machine databases; INI, Config, and UDL files; etc.).
MSP-based patching is a more advanced topic. You might begin by reading Patching and related articles at MSDN.
When you try to update "around the side" by replacing an EXE, etc. Windows Installer catches this and tries to "heal" the tampering that has taken place. This is a feature, not a bug.
When you try to update "around the side" by replacing an EXE, etc. Windows Installer catches this and tries to "heal" the tampering that has taken place. This is a feature, not a bug.
Yeah, I knew it was not a bug, but I like features that can be turned off. =)
The tricky thing is that my application is actually like 10-15 programs. Some .NET, some VB6, some maintained by me, others by their contributing authors. So on major releases I distribute everything, but if a contributing author updates one of his little apps, we would like people to download that without me putting out a full update across all the apps.
I will try some of these suggestions today and see what I can work out.
Reply With Quote
Originally Posted by dilettante
