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.
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.
MicrosoftFor 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.
- James Pike
That does not sound like behavior I would expect.
If you could file feedback and if possible share your specific packages, that would help us see if there is something special about your use case that is causing unexpected behavior.
Thanks!
James
Hi James,
Attached you find a ZIP file that contains all the files. I also added a little readme how to. It is a simple application. We want to install the Common files default on the machines with CM because it contains drivers.
Hi James,
Thanks for the advice. That helped me out on this. I made two new MSIX packages from 18.2 and 18.3 with the same Identity Name. Then upgrade works flawless.