Packaging on a 1809 or a 1909 gets different results !

[RaulCosta]

Hello to all,

I've repacked a software using 1.2020.1219.0 MSIX repackager on a Windows 1909 machine (including PSFTooling version 4.4.20.0).

Installed correctly and started ok on a clean Windows 1909.

Installed correctly but did not started ok on a clean Windows 1809.

When I repacked the same software an a 1809 using the same repackager I was able to install and run the software on both 1809 and 1909 machines.

Anyone had a similar experience ?

[#2]

Hi @RaulCosta 

Try to unzip the two MSIX  packages and compare the list of files present in each package (using tools like Beyond Compare or something similar) to see if any additional files are included in the 1809 package.

It sounds like your old installer (the one you are converting) might install different dependencies for your app, depending on the OS version. This is a classic situation for repackaged application, no matter if your are repackaging an EXE to build an MSI or MSIX.

[#3]

@Bogdan Mitrache I can confirm that side-by-side compare was done and all application files are 100% equal.

I had already done that compare.

It really looks like is something related to MS Repackager/OS Version.

[#4]

Hi @RaulCosta 

Well, besides the files the reppackager also build the registry.dat hives and the appxmanifest. Have you compared these ones too?

Since one of the packages works and another doesn't there surely must be a difference between them. I assume you are running/testing them in clean VMs so there is no way the MS repackager or other resources from the machines can interfere with the test.

[#5]

@RaulCosta  I can let you know that there should be no difference in what PsfTooling did that depends upon the OS you package on. I don't know about the MMPT, but I'd be surprised that would behave differently.  More likely, there was something slightly different in the setups.

Also double check the min version / max version tested fields in the manifest.  That would be different in the MMPT.

Assuming that the failure occurs immediately, since you have the PSF added I'd recommend using DebugView while launching to see if there is a clue being posted to the debug console.

[#6]

@TIMOTHY MANGAN thank you in advance,

It looks like on the 1809 version it was able to inject the DynamicLibraryFixup32.dll and the other one just died. Strange but maybe there was a human error creating one of the packages. 

DebugView logs are attached. (added as zip with both files because this website doesn't support TXT files).

Min / Max version on both:

<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.18335.0" />

And both created with:
<!--Package created by MSIX Packaging Tool version: 1.2019.1220.0-->

and with PsfTooling 4.4.20.0

The config.json is a match as are all existing application files.

I will recreate both MSIX from ground-up to confirm the step-by-step on both.

[#7]

@RaulCosta  It looks like in the failed case, the app is crashing while PsfRuntime is initializing, right after finding the correct process entry in the config.json file.  So at that time it would have been processing those entries.  

I would look at the config.json files for comparison to see if there is something obvious.  If you are willing to share the packages I can take a quick look.  Email me at tmangan@tmurgent.com. 

PS: A new release of PsfTooling went out last Friday.  I don't recall anything that sounds like this in the release, but it does have an updated Psf.

[#8]

Thank you @TIMOTHY MANGAN I will send via email.

When will you have a offline version of it so we can install without having to use the store ? :)

[#9]

@RaulCosta Oh yeah, I was going to do that!  It is on the never-ending list of projects.