Forum Discussion
Modification Package not doing what I want
For this scenario, consider doing a second full conversion of your 18.3 installer. That should give you the cleanest capture of the file and registry changes. Keep the package identity the same as the package you created for 18.2 and just increment the version number of the MSIX.
By virtue of being MSIX packages, when you install the 18.3 package, the deployment process will compare the block hashes of the new package with the existing installation. It will attempt to scope the actual deployment work to only files that have changed. Additionally, this update should preserve the apps user data, so only the underlying installation files should change.
Note: If you have configuration that is contained within the apps installation files or registry keys, that's where you might consider leveraging a modification package. The modification package can persist across full updates, so if you needed to always customize a particular registry key, for instance, the modification package would be appropriate.
Hi, yes that is what I want to achieve. I made an MSIX of 18.2. That works fine. Now I have a 18.3 executable and my thoughts were to create a modification package to upgrade 18.2 on the machines. The modification package creation went fine and I can install it but the shortcut keeps running 18.2. So I think I misunderstand the behaviour of modification packages.
MicrosoftRight, modification packages are used to customize main packages. Looks like you are trying to update your existing MSIX to the next version. You can do this in MSIX Packaging tool under package editor and changing the executable. Make sure to update the version number of your package and resign your package.
Helpful docs https://docs.microsoft.com/en-us/windows/msix/packaging-tool/package-editor
Ok, clear. I can do this in this situation because only the exe is changing. But what is the right procedure to update an application to a newer version that changes a lot more like a hundreds of files and registry keys? Because that becomes a lot of work then if you must do that with packaging editor. And we will definitly have these kind of applications since we are an engineering company with lots of calculation programs like Tekla Structures for example.
James PikeFor this scenario, consider doing a second full conversion of your 18.3 installer. That should give you the cleanest capture of the file and registry changes. Keep the package identity the same as the package you created for 18.2 and just increment the version number of the MSIX.
By virtue of being MSIX packages, when you install the 18.3 package, the deployment process will compare the block hashes of the new package with the existing installation. It will attempt to scope the actual deployment work to only files that have changed. Additionally, this update should preserve the apps user data, so only the underlying installation files should change.
Note: If you have configuration that is contained within the apps installation files or registry keys, that's where you might consider leveraging a modification package. The modification package can persist across full updates, so if you needed to always customize a particular registry key, for instance, the modification package would be appropriate.
Hi James, tested a bit more and it seems that the 18.3 update doesn't get its registrykeys ok after upgrading the 18.2.
If I install the 18.3 when the 18.2 is not installed my settings in the application show ok.
When I first install the 18.2 and then upgrade with the 18.3 the application uses the default settings while I set them different during the "First Run"step in the MSIX Packaging Tool.
In this case when I go to the App settings of the 18.3 and do a "Reset" of the app the settings after starting the application are OK again.
The 18.2 and the 18.3 use both the same registrykey and values in the Current user part.
Can this be solved somehow so there is no Reset needed.