[BUG] Version downgrade in .NET 7 for System.IO.Compression.Native.dll leads to broken Microsoft Installers

[czdietrich]

Description

From .NET 6 to .NET 7 the version schema of System.IO.Compression.Native.dll has changed and is now lower than before. When an application is compiled as self-contained and bundled into an MSI file, upgrading from a previous (e.g. .NET 6) version will lead to an issue in the Microsoft Installer installation process.

Reproduction Steps

1. Create a new application (e.g. dotnet new console -f net6.0)
2. Create a global.json (e.g. dotnet new globaljson --sdk-version 6.0.100)
3. Publish the app as self-contained application (e.g. dotnet publish -c Release --self-contained true -r win-x64)
4. Bundle the application as MSI file (e.g. use WiX toolset or skip this step for now)
5. Repeat steps 1 to 4 for .NET 7.0 (-f net7.0 and --sdk-version 7.0.100)

Expected behavior

The latest DLLs for .NET self contained builds will be deployed when installing using MSI if there is a previous installation using .NET 6.

Actual behavior

In case you created MSI files:

Install the MSI from the first run and then upgrade the installation using the MSI from the second run.
Inspect the installation directory: System.IO.Compression.Native.dll is missing.
If you repeat this but you do a fresh installation of the second run, System.IO.Compression.Native.dll would be correctly placed in the installation folder.
In the end this means upgrading or fresh installing will lead to different results.

In case you did not build MSI files:

Inspect Publish-folder of both dotnet publish-runs. You will see that System.IO.Compression.Native.dll has a higher file version number for .NET 6 build than for the .NET 7 build.

Regression?

A similar issue existed in .NET 6 and got fixed. Maybe there could be some test checking for these kind of version conflicts to prevent this class of issues in the future?

Known Workarounds

No response

Configuration

No response

Other information

Further technical details

It is important that the file version of a DLL does not downgrade for a newer installer compared to the currently installed DLLs.
More info about this can be found here:
https://stackoverflow.com/questions/47157021/downgraded-ms-dll-disappears-on-upgrade-windows-installer
https://docs.microsoft.com/de-de/archive/blogs/astebner/why-windows-installer-removes-files-during-a-major-upgrade-if-they-go-backwards-in-version-numbers
https://docs.microsoft.com/en-us/windows/win32/msi/both-files-have-a-version

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

From .NET 6 to .NET 7 the version schema of System.IO.Compression.Native.dll has changed and is now lower than before. When an application is compiled as self-contained and bundled into an MSI file, upgrading from a previous (e.g. .NET 6) version will lead to an issue in the Microsoft Installer installation process.

Reproduction Steps

1. Create a new application (e.g. dotnet new console -f net6.0)
2. Create a global.json (e.g. dotnet new globaljson --sdk-version 6.0.100)
3. Publish the app as self-contained application (e.g. dotnet publish -c Release --self-contained true -r win-x64)
4. Bundle the application as MSI file (e.g. use WiX toolset or skip this step for now)
5. Repeat steps 1 to 4 for .NET 7.0 (-f net7.0 and --sdk-version 7.0.100)

Expected behavior

The latest DLLs for .NET self contained builds will be deployed when installing using MSI if there is a previous installation using .NET 6.

Actual behavior

In case you created MSI files:

Install the MSI from the first run and then upgrade the installation using the MSI from the second run.
Inspect the installation directory: System.IO.Compression.Native.dll is missing.
If you repeat this but you do a fresh installation of the second run, System.IO.Compression.Native.dll would be correctly placed in the installation folder.
In the end this means upgrading or fresh installing will lead to different results.

In case you did not build MSI files:

Inspect Publish-folder of both dotnet publish-runs. You will see that System.IO.Compression.Native.dll has a higher file version number for .NET 6 build than for the .NET 7 build.

Regression?

A similar issue existed in .NET 6 and got fixed. Maybe there could be some test checking for these kind of version conflicts to prevent this class of issues in the future?

Known Workarounds

No response

Configuration

No response

Other information

Further technical details

It is important that the file version of a DLL does not downgrade for a newer installer compared to the currently installed DLLs.
More info about this can be found here:
https://stackoverflow.com/questions/47157021/downgraded-ms-dll-disappears-on-upgrade-windows-installer
https://docs.microsoft.com/de-de/archive/blogs/astebner/why-windows-installer-removes-files-during-a-major-upgrade-if-they-go-backwards-in-version-numbers
https://docs.microsoft.com/en-us/windows/win32/msi/both-files-have-a-version

Author:	czdietrich
Assignees:	-
Labels:	area-Infrastructure-libraries, untriaged
Milestone:	-

[cz-dev-ge]

This affects me as well.

[czdietrich]

This issue exists now for almost 3 months and is still untriaged.
Please have a look, this is a serious problem and can easily break several installations.

[nblumhardt]

This class of issue occurs quite a lot when bundling up MSIs that pull in a lot of framework/third-party components. We hit this particular issue upgrading Seq from .NET 6 to .NET 7, and used the same strategy we've had to employ a couple of times in the past.

In a nutshell, MSI has the concept of "companion files" that "donate" version information for the incorrectly-versioned one. In our case, we configure System.IO.Compression.dll to be the companion to (the broken) System.IO.Compression.Native.dll. This works like magic and is pretty robust, as long as you can pick an appropriate companion.

If you're using WIX Toolset, you set up companion files by creating a component that includes both files, and uses the CompanionFile attribute on the File element:

https://wixtoolset.org/docs/v3/xsd/wix/file/

There are some examples of this being done on the WIX mailing lists, IIRC.

Good luck!

(Also, I LOL'd when we spotted this and realized what the original version number was :-D - oops. Just the kind of thing I'd have done myself!)

[ViktorHofer]

Sorry for taking longer to respond. We actually already talked about this internally a while ago but we missed to reply.

Unfortunately, the native assembly in .NET 6 had an incorrect file version 42.42.42.42 which we then later realized and fixed during .NET 7. While the fix is inconvenient as it broke incremental MSI installer upgrades, it was the right thing to do as the previous file version was incorrect.

Please see @nblumhardt response for a workaround.

[cz-dev-ge]

There might be another possibility. I know it won't look nice, but what if you use some offset to fix the behavior? Instead of 7.0.1.0 it could be 47.0.1.0. Upgrading would still be possible and it's still visible what version number is intended.

Another option would be to deprecate the assembly and replace it with a copy with another identifier - upgrade by replacement.

Best regards.

[czdietrich]

OK, we now utilize the CompanionFile feature of WIX to handle this kind of version change. And now it seems to work as expected when doing an upgrade. Thank you again for this tip.

This being said, I think it would be good to also list these kind of changes in the Breaking Changes section of new .NET releases, because I expect that there are now several broken installers out there which package self contained .NET applications.