SOLVED

Modification Package not doing what I want

Copper Contributor

Hi,

I am struggling with a modification package. I created an MSIX for a 18.2 version of an application. That works like a charm. Now I wanted to create a modification package for version 18.3. Basically it is just one exe file with the same name as for 18.2 that gets replaced. I had the expectation that during the modification package creation process there would be a step to record the first run options but there isn't. I run the installer for the 18.3 version and the modification package gets created. I can also install it after the 18.2 is present. But when I launch the shortcut I get the 18.2 started instead of the 18.3. This is not what I want/expected. I also tried with the 18.2 already installed (original installer) and then install the 18.3 but that gives the same result. Anyone excperienced something like? Can't figure out what i am doing wrong here.

21 Replies

Hi, are you trying to create a new version (18.3 version) of your application that you converted into an MSIX (18.2 version)? 

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.

Right, 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.

best response confirmed by RRobesin (Copper Contributor)
Solution

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 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.

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.

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 Robesin,

 

I just tried this.

I installed your 18.2 package, launched, and closed the first-run dialog, then

I installed your 18.3 package, launched, and closed the first-run dialog again.

 

Is the problem that the first-run dialog appears the 2nd time?

 

> 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.

 

How can I see these default settings that are wrong?

Is there a specific registry-key that is wrong after the upgrade is complete?

 

Thanks!

-jw

Hi, when I captured the program during first launch I checked the box to not show the EULA. I know the MSIX is not completely clean but this are just tests done. The behaviour I see is:

I install 18.2 - I see no EULA dialog.

I update to 18.3 - I see a EULA page, I can check the box what I want but with next start it shows it again.

I go to App settings and reset my App 18.3. Then after startup the EULA is not shown.

 

Is the problem that the first-run dialog appears the 2nd time? Yes, setting is not saved somehow.

 

Does such an App interfer with local registry keys? Or how is that arranged?

> I install 18.2 - I see no EULA dialog.

 

Weird - I do see the EULA dialog with version 18.2.

 

But regardless, the behavior you're seeing shouldn't be happening - when you upgrade to 18.3, you should still see no EULA if you saw no EULA for 18.2.

 

> Does such an App interfer with local registry keys? Or how is that arranged?

 

Any writes to HKCU (from version 18.2 of the app) should be persisted and visible to version 18.3 when it is installed.

 

What key is the EULA code writing to?

Hi
It is the key hkcu/software/deltares/dgeopipeline/preferences/iseulaaccepted as far that I know. At the moment I am not at the office. If the value is 0 it doesn't show the eula.

Hi Robesin - I just got another report about an app that is hitting an ACCESS DENIED when trying to write to HKCU at app-runtime when the app has a User.dat file in it.

 

Can you try removing the User.dat file from your package and see if that fixes your problem?   (If this is actually the problem, we will file a bug and fix this.)

 

Thanks!

Hi Jeff,

 

Sorry it took a while but I had other things to attend to. I rebuild the packages of 18.2 and 18.3 without capturing any first startup.
I verified that in the MSIX files are no keys for the program under HKCU

Then I followed the next steps:


Step 1 to check 18.2 behavior
- Install MSIX 18.2 and let it launch

- Check the box to hide the EULA at next start, Set Tools,Options, Modules, Close the program

- Start the program things look ok, settings are retained.
- Uninstall 18.2 version

 

Step 2 to check 18.3 behavior
- Install MSIX 18.3 and let it launch

- Check the box to hide the EULA at next start, Set Tools,Options, Modules, Close the program

- Start the program things look ok, settings are retained.
- Uninstall 18.3 version

 

Step 3
- Install MSIX 18.2 and let it launch

- Check the box to hide the EULA at next start, Set Tools,Options, Modules, Close the program

- Start the program things look ok, settings are retained.
- Install the MSIX 18.3 (UPDATE) and let it launch, now existing settings in HKCU from 18.2 are not retained
- The EULA shows up again even though it is the same HKCU key as in the 18.2 version.
HKEY_CURRENT_USER\Software\Deltares\D-Geo Pipeline\Preferences[IsEulaAccepted]

- I can check the box again to hide the EULA at next start, and Set Tools,Options, Modules, Close the program (which shouldn't be necessary because of 18.2)

- Then start the program things look ok, settings are retained again.

 

This is not OK since exact the same key is also present in 18.2 and shouldn't be reset by the upgrade to 18.3. So it seems something goes wrong there. It should let the HKCU keys from 18.2 live and reuse.

 

I added the MSIX files I used for this. Common files from the prior post need to be installed to use these files.

Hey Robesin.  Thanks for re-running the steps.

 

I still see the User.dat file in your package.  Can you try removing it with the MPT (Msix Package Tool), and try this test again.  I believe there's a bug on our end where having a User.dat file makes writing to HKCU (at runtime) fail.

 

Untitled.png

 

If you can confirm this, then I'll file the bug and get the fix going.

 

Thanks!

 

Edit:  I think the MPT tool has a feature called "Package Editor" that can be used to remove the User.dat from the package.  (It seems it's not enough to just uncheck the "First-Run" option in the MPT.)  Apologies for all the back and forth.

Hi Jeff,

I removed the user.dat from the MSIX packages with the packaging tool. Checked by unzipping the MSIX and confirm that there is no user.dat file in it. It took a while but we have a very busy schedule at the moment. Then I tested the following.

- Install the 18.2 MSIX

- Start the application and Check the EULA to not show it again, Go to the Tools. Program Options, Modules, check "Show at start of Program", OK

- shutdown the app and start it again. Settings are retained, EULA is not shown and Modules dialog is shown. so far so good.

- Now I run the 18.3 MSIX asking to Update, go ahead

- Start the app and it shows 18.3 is starting.

- The EULA is shown. This shouldn't happen since it is exact the same registry key as for 18.2

HKEY_CURRENT_USER\Software\Deltares\D-Geo Pipeline\Preferences\[IsEulaAccepted]

- Go to the Tools. Program Options, Modules, "Show at start of Program" is NOT checked anymore. This should be checked as it uses exact the same key as in 18.2

HKEY_CURRENT_USER\Software\Deltares\D-Geo Pipeline\Preferences\[ModulesDlgAtStartUp]

 

Upgrading seems only to work for the files but not for the user registry. I suppose it should determine the registrykey settings from 18.2 and respect them for 18.3 if not set different in 18.3 off course.

To me this seems a bug but I will leave that decision to you. I attached the used MSIX files.

Hey Robesin,

 

Upgrading seems only to work for the files but not for the user registry. I suppose it should determine the registrykey settings from 18.2 and respect them for 18.3 if not set different in 18.3 off course.

 

Yes agree.

 

I tried your latest V04 version, and it seems to me like the value of IsEulaAccepted is '1' after upgrading from 18.2 to 18.3, but the D-Geo application is setting it back to '0' at runtime.

 

1. Installed 18.2 - Launched & Accepted EULA.

     i. Open powershell.exe

     ii. Add-AppxPackage C:\t\V04\Deltares-GeoPipeline_18.2.0.0_x64__m1y3p73dxj1ne.msix -ForceApplicationShutdown

 

2. Verify that IsEulaAccepted is '1'

    i. Enable Devmode

    ii. Open powershell.exe

    iii. Invoke-CommandInDesktopPackage -PreventBreakaway -PackageFamilyName Deltares-GeoPipeline_m1y3p73dxj1ne -AppId abcd -Command regedit.exe

    iv. Navigate to Computer\HKEY_CURRENT_USER\Software\Deltares\D-Geo Pipeline\Preferences

    v. I see IsEulaAccepted is '1'

 

3. Installed 18.3

     i. Open powershell.exe

     ii. Add-AppxPackage C:\t\V04\Deltares-GeoPipeline_18.3.0.0_x64__m1y3p73dxj1ne.msix -ForceApplicationShutdown

 

4. Verify that IsEulaAccepted is still '1'

    ii. Open powershell.exe

    iii. Invoke-CommandInDesktopPackage -PreventBreakaway -PackageFamilyName Deltares-GeoPipeline_m1y3p73dxj1ne -AppId abcd -Command regedit.exe

    iv. Navigate to Computer\HKEY_CURRENT_USER\Software\Deltares\D-Geo Pipeline\Preferences

    v. I see IsEulaAccepted is still '1'

 

5. Launch D-Geo & verify that IsEulaAccepted is still '1'

      i. I used procmon to verify that D-Geo is getting '1'

2:14:40.8339332 PM DGeoPipeline.exe 10760 RegQueryValue \REGISTRY\WC\Siloa6f2f44c-9d06-02e3-97d4-f3733e69c2e5user_sid\Software\Deltares\D-Geo Pipeline\Preferences\IsEulaAccepted SUCCESS Type: REG_DWORD, Length: 4, Data: 1

 

6. Close D-Geo & see in procmon that D-Geo sets IsEulaAccepted to '0'

2:15:09.2006347 PM DGeoPipeline.exe 10760 RegSetValue \REGISTRY\WC\Siloa6f2f44c-9d06-02e3-97d4-f3733e69c2e5user_sid\Software\Deltares\D-Geo Pipeline\Preferences\IsEulaAccepted SUCCESS Type: REG_DWORD, Length: 4, Data: 0

 

7. Verify that IsEulaAccepted is '0'

    ii. Open powershell.exe

    iii. Invoke-CommandInDesktopPackage -PreventBreakaway -PackageFamilyName Deltares-GeoPipeline_m1y3p73dxj1ne -AppId abcd -Command regedit.exe

    iv. Navigate to Computer\HKEY_CURRENT_USER\Software\Deltares\D-Geo Pipeline\Preferences

    v. I see IsEulaAccepted is '0'

 

I can't really deduce much else from this though.  I think this is the stack trace where D-Geo is setting the eula to '0', but I don't have symbols or source code for D-Geo to interpret it further.

 

18 KernelBase.dll RegSetValueExA + 0x10d 0x7690bc1d C:\Windows\SysWOW64\KernelBase.dll
19 DGeoPipeline.exe DGeoPipeline.exe + 0x3686b 0x43686b C:\Program Files\WindowsApps\Deltares-GeoPipeline_18.3.0.0_x64__m1y3p73dxj1ne\VFS\ProgramFilesX86\Deltares\DGeoPipeline\DGeoPipeline.exe
20 DGeoPipeline.exe DGeoPipeline.exe + 0x3671d 0x43671d C:\Program Files\WindowsApps\Deltares-GeoPipeline_18.3.0.0_x64__m1y3p73dxj1ne\VFS\ProgramFilesX86\Deltares\DGeoPipeline\DGeoPipeline.exe
21 DGeoPipeline.exe DGeoPipeline.exe + 0x4175c2 0x8175c2 C:\Program Files\WindowsApps\Deltares-GeoPipeline_18.3.0.0_x64__m1y3p73dxj1ne\VFS\ProgramFilesX86\Deltares\DGeoPipeline\DGeoPipeline.exe

 

Hopefully you can make something of this.

 

Thanks,

-jw

Here's the screencap (in procmon.exe) of 18.3 querying and getting '1'.

 

a.png

1 best response

Accepted Solutions
best response confirmed by RRobesin (Copper Contributor)
Solution

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.

View solution in original post