Upgrades without uninstall

[Trigve]

Hello,
I'm trying to implement upgrades without uninstalling the files first, just the replacing the changed files. I've made it work in pure wix with this tags

<MajorUpgrade DowngradeErrorMessage = "..." Schedule = "afterInstallFinalize" />

<Upgrade Id = "...">
	<UpgradeVersion OnlyDetect = "yes" Property = "XVERSIONLOW" Maximum = "24.03.0" IncludeMaximum = "no" />
</Upgrade>

<CustomAction Id = "UpdateFromVersionNotSupported" Error = "..." />

<InstallUISequence>
	<!-- Need to be called before any action could be done. This is shown only if the installed version is too low -->
	<Custom Action = "UpdateFromVersionNotSupported" After = "FindRelatedProducts" Condition = "XVERSIONLOW" />
</InstallUISequence>

I've tried to make it same with wixsharp but it just doesn't work and during upgrades the components are uninstalled at the end and installation is "corrupted". Comparing the msi using Orca doesn't revealed any differences. Am I doing something wrong?

[oleg-shilo]

I'm trying to implement upgrades without uninstalling the files first,

You cannot achieve that. MajorUpgrade (you use this element) means that you always uninstall the old version of the product.

If somehow your pure WIX works then you can simply ensure that WixSharp emmits the same WXS and the result will be the same too.

[Trigve]

Thanks for the quick reply.
According to the https://stackoverflow.com/questions/47391042/major-upgrade-without-uninstallation-of-windows-service the important part is sequencing, that is if the MajorUpgrade schedule is afterInstallExecute than it practically should overwrite the new files.

If somehow your pure WIX works then you can simply ensure that WixSharp emmits the same WXS and the result will be the same too.

I'm generating the same output from the wixsharp as I have with pure wix, but somehow it doesn't work (I'll try it once more though to be sure). So I want to be sure that wixsharp isn't "injecting" some tags I didn't noticed (because, you know it is large files and I skip the components, files, etc. when comparing it with pure wix).

[Trigve]

Never mind. I've rewritten the project using classic major upgrade (uninstall/install) with preserving the data needed. The only problem I have now is being able to detect during UI (modified managed UI) if this is and upgrade or not. I've read https://github.com/oleg-shilo/wixsharp/wiki/Detecting-upgrade-at-runtime , #1123 (and also other posts, issues, examples) but IsUpgradingInstalledVersion() is always returning False. Looking through the msi log, I don't see any properties being set used by upgrades so I'm bit puzzled.

[oleg-shilo]

For the IsUpgradingInstalledVersion(), if for whatever reason it does not work for you can always manually search the registry for the required "UpgradeCode".
It's not an elegant solution but it's simple and reliable. You only need to find the exact location of the key in the registry.
Keep in mind that you need to do it before the perv version is uninstalled. Otherwise you loose this info.

You can also try to use CommonTasks.AppSearch.GetProductVersionFromUpgradeCode("<your upgrade code>"). This method used MSI API MsiEnumRelatedProducts.

[Trigve]

I see. The other workaround that worked for me is LookupInstalledVersion().

[oleg-shilo]

Great. It is actually the same code :)

[Trigve]

I have one more question, which is somehow connected with this discussion.

Our .msi does contains multiple stuff like postgres server, application, application modules, support apps, ... (and each customer has a custom .msi build only for him, because of combination of some stuff which isn't important here - so all the .msi are generated automatically). Because of this, msi is quite big at around 100 MB. Now, when some update is done to the app modules, there is no need to reinstall all the stuff (sql, ...). The modules should suffice which could have size of single megabytes.

The only solution I can think of now is to split the single big .msi to the modules, so the sql would be solo .msi, application solo .msi, app modules solo .msi and so long. Then I would create simple bootstrapper native exe (maybe with some gui where options could be configured) which would run all the .msi sequentially. So if minor update of the app modules occur, I will only bundle the app module .msi and nothing more and therefore only modules would be upgraded.

Does is sound plausible? Or is there any other option available?

[oleg-shilo]

There is a more direct solution to that - patch. Minor upgrade concept.
While it seems like an attractive option I really dislike the minor upgrade as it creates more problems than it solves. No wonder it has been abandoned in the later deployment frameworks.

Thus your approach seems a better choice to me. However, I would still ask myself (if I were you). Is it worth the effort of building the bootstrapper and handling multiple msis only to avoid a large msi? If the answer is yes, then I would go with multiple MSIs.

[Trigve]

Yeah, I've tried to make some prototype and even if it worked, there were numerous problems and solving them could take some time. So I've just postponed it to indefinitely.