I am releasing a new version of my product (minor upgrade), which I'm planning to package as a patch. This is a Basic MSI project in InstallShield 2009.
The installer creates some shortcuts on the desktop and in the All Program menu, this shortcuts make a reference to the version number, e. gr. "My Product 7.3", "My Product 7.3.2".
The change in the name of the shortcut is causing that after the upgrade is finished, the system ends up with duplicated shortcuts, one for version 7.3 and a second for version 7.3.2.
I made some research on this and started using the RemoveFile table, this worked fine when I created my patch 7.3.1, but now in patch 7.3.2 it isn't working in some cases. Let me clarify this.
This scenario DOES work:
I install my product version 7.3 (full installer)
Run patch 7.3.1 (windows installer patch). Shortcut for 7.3 is deleted fine.
Run patch 7.3.2 (windows installer patch). Shortcut for 7.3.1 is deleted fine.
This scenario does NOT work:
I install my product version 7.3
(full installer)
Run patch 7.3.2
(windows installer patch). Shortcut
for 7.3 is NOT deleted.
Note: I have tested my 7.3.2 version by running the full installer instead of the patch, and it works fine. It performs the minor upgrade and removes the old shortcut.
In my 7.3.2 patch I've added both 7.3 and 7.3.1 as previous setups.
A verbose log doesn't seem to provide much information (or probably I'm not doing the right search).
The component associated to the records in the RemoveFile table is updated correctly which I can verify in the log:
MSI (s) (58:EC) [15:51:44:846]: Component: ProgramFiles; Installed: Local; Request: Local; Action: Local
I will appreciate any help that you may provide.
Thanks.
Juan Carlos
Check the patch installation works, if only 7.3 is inclided in previous setups.
Seems like the problem in this case was related to the fact that when I accidentally changed the source files when creating the patch. So the file table didn't match with the files that I was really shipping. This created some sort of conflict with the upgrade. I've repeated the scenario using always the correct files and it worked fine.
Related
Building MSIs with WixSharp since years, I always followed this rule which basically says:
For each new release of your application, change the ProductCode but never change the UpgradeCode.
This always worked perfectly but recently I discovered that installing a newer release of my application does not replace the previous version but instead is getting installed in parallel.
Running this PowerShell script gives me this result on a test machine:
My question
What is the reason that a MSI file does not replace an existing one upon installation with the same UpgradeCode?
(I've also posted this as a question on the WixSharp GitHub repository)
Update/solution
I've finally managed to solve it. Basically I did the following things:
Removed the version string from my setups name (since MSI seems to also compare then names to check whether an upgrade is possible; only the same name seems to fit)
Changed my version number from 4 to 3 digits, as Christopher pointed out. I.e. I'm now incrementing e.g. "1.0.0" to "1.0.1" etc.
Added this code to my WixSharp ManagedProject instance:
InstallScope = InstallScope.perMachine,
MajorUpgradeStrategy = new MajorUpgradeStrategy
{
UpgradeVersions = VersionRange.OlderThanThis,
PreventDowngradingVersions = VersionRange.NewerThanThis,
NewerProductInstalledErrorMessage = "Newer version already installed.",
RemoveExistingProductAfter = Step.InstallInitialize
},
After these changes, an upgrade succeeded.
The constraint is ProductCode not UpgradeCode. Only 1 MSI per ProductCode can be installed. Attempting to do so again will be a maintenance operation, small update or minor update.
Many MSI can share an UpgradeCode. (Not a good practice though!) For example it's not required for you to author a Major Upgrade at all.
The usual cause here though is you must change the version number in the first three fields and each install must be in the same context (per-user and per-user or per-machine and per-machine). BTW that's another way to install the same ProductCode twice. One per-user and one per-machine. Again not a good practice.
Good:
1.0.0 → 1.0.1 FindRelated Products in the 1.0.1 MSI will see the 1.0.0 and tell RemoveExistingProducts to remove it.
1.0.0 → 1.0.0 or
1.0.0.0 → 1.0.0.1 Bad. FindRelated will see it as the same version and not remove it.
A while ago I've created a offline install layout for VS2017 Professional (Version 15.5) - this is the base for a couple of dev-hosts at work.
Now we want to upgrade to VS2017 - version 15.8 - so I've createad a 1:1 copy of the existing layout and ran
vs_Professional.exe --layout <path_to_layout>
which ran for a while and updated ?all? packages in the layout.
doing a clean install with this updated layout does work well, however - when using this layout to update one of the hosts that have version 15.5 installed the update procedure fails with exit code "1".
sidenote: VS actually states that it's now 15.8.4 - but it exits with an error code .. so ..?
the command I use for install/update is
(drop the "update" for the clean installation)
vs_Professional.exe update --passive --norestart --wait --productkey $productKey --nocache --noUpdateInstaller --noWeb
using collect.exe there is a state.errors.json file which states that a couple of packages are missing on the layout path...
NOTE: I need to have all required packages available in the offline layout - because some of the PCs do not have internet access (despite we've got the requirement that those vs-setups need to be identical...)
I've tried to reach out to Microsoft Support but didn't hear back from the till now. - anyone else having this issue / was able to solve it?
The update process of an MSFT Visual Studio offline layout seems to be rather buggy, yet there is at least 1 way which seems to work consistently:
always, always, always note the exact parameters you've used to create a offline layout! (all packages, included extras, language - the exact command line(s) you've used!
1: create a copy of the existing offline layout
You'll want to do that if you need to be able to keep using the old layout version for new installs, as Sara Liu pointed out in the comments of the original question. (installing a 'older version' of an updated layout is not supported.)
Also, in case something breaks during the update - you don't loose anything ;-)
2: update the duplicated offline layout
vs_Professional.exe --layout <path_to_layout>
after this finished you should be able to install the new VisualStudio version from this updated layout, yet upgrading a older version will probably fail.
To resolve this, MSFT gives you the
vs_Professional.exe --verify
vs_Professional.exe --fix
tools you can throw at your layout - but don't expect it to work - it never figured out what packages have been missing in my scenarios.
if you follow point 3, you'll also be able to upgrade existing installations.
3: create a new layout with the same parameters as the original one and copy the files over the updated layout
it's quite weird I know - but this has given me the missing packages for the upgrade scenario all the time. just don't forget to fix your ChannelManifest.json afterwards.
I have an app that uses a VS 2015 installer project.
Our BONEHEAD vendor, ComponentOne, released a new version of several assemblies upon which my product depends.
Here's the rub:
Old DLL version: 4.1.20102...
New DLL Version: 4.0.20162...
The newer DLL at least have newer file dates than the older one.
Of course, the newer DLL fix real user problems brought about by the bugs in the C1 components since corrected.
While I can get to the correct DLL by having the end user fully uninstall the older version of my product and installing the newer version, this is unworkable because:
We have an auto-update function that phones home and checks for the latest patch and installs it to update prevoius version; and
Our customers are female, 60+ and cyberphobic.
The project already has the RemovePreviousVersions property set to true, and I was hoping that this did a complete uninstall silently. It does not; the six assemblies with the version error are not replaced. The DetectNewerInstalledVersion property is also set to true; I tried to install with False, and it has no effect.
I also tried to explicitly include all detected dependencies of the C1 assemblies and it has no effect.
Is there a way to force the install project to overwrite the assemblies as long as the file date is newer regardless of the wrongly-encoded version?
Edited to add the following:
I tried making a custom action to delete the offending assemblies before installing anything - it runs after the files are installed. :(
I tried InstallShield LE, only to find out that it could not discover the dependencies more than one level deep, and provided no convenient way to explicitly specify the dependencies. I also could find nothing that would let me say to overwrite the assemblies based on date or unconditionally.
Thanks for any help you can offer!
I found an effective workaround.
I already had RemovePreviousVersions set to true, so I changed the application's default folder by adding [ProductVersion] onto the end of the path.
What this accomplished was:
It deleted the old assemblies; and
It created the new assemblies in the new folder.
This solved the problem nicely. No setting REINSTALLMODE to amus; no brute force solutions.
I'm setting up a installation (.exe) for Office Plugin and using Installshield limited edition. I have old version 1.0 was distributed and used by end-user, right now I would like to redistribute new version 2.0, and would like to make program to remove or override completely old version when install new version.
I tried "upgrade path" to change product code but it seem does not override completely old version.
Does anyone can help or let me know there is any way to do that?
Thank you!
Ok, I got solution now. Beside change Product Code & Product version I have to change INSTALLDIR path to resolve it.
Step to do it:
Step 1: From installshield => Select upgrade path => add new => Browse to old version (.exe), to get Upgrade Code. If the app support multi-language with multiple install file (.exe) version we need to add all these old version in upgrade path
Step 2: From installshield go to "General Information Tab" to check make sure Upgrade Code is the same, then change product code and Product Version
Step 3: From installshield go to "General Information Tab" to change INSTALLDIR path for new version, for example from MyApp1.0 to MyApp2.0
The feature list, states:
"It has an easy-to-use single-file installer that creates a working installation with just a few clicks, and can update that installation when new packages become available."
Great, but how to do the update? If I run the installer and "manage" my installation, nothing is updated at all.
Ok, the problem was that I used the "[current installation]" option thinking, that this will update, well... my current installation. Which is wrong. It doesn't do anything.
So, you need to select on of the other options and it will download what you have selected.