Microsoft.DiaSymReader.Native.amd64.dll version downgraded in 7.0.12 service pack

[czdietrich]

Description

The version of Microsoft.DiaSymReader.Native.amd64.dll is smaller in .NET Core runtime in 7.0.12 than it was in 7.0.11. This is a problem for self-contained applications that use Microsoft installer framework (WiX) to build their installers, since this will lead to the issue that this DLL will be missing after updating from an existing installation with the previous DLL version.

Reproduction Steps

Just compare the DLL versions of Microsoft.DiaSymReader.Native.amd64.dll for .NET 7.0.11 (14.29.30152.0) and 7.0.12 (14.29.30150.0).

Expected behavior

The version of the DLL should be at least 14.29.30152.0, which is the version being used in .NET 7.0.11.

Actual behavior

The version of the DLL is 14.29.30150.0, which is smaller than 14.29.30152.0, the version being used in .NET 7.0.11.

Regression?

I would say yes.

Known Workarounds

In WiX one can define a companion DLL for another DLL which makes the installer to not make a version check. See comment.

But it is unclear whether this DLL has an obvious companion to use here.

Configuration

.NET 7.0.12. But the issue also exists in .NET 6.0.23 and probably other .NET versions too.

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

See also:
#82518
#62218

[cz-dev-ge]

As mentioned in #93570 using the companion approach would mean to force installation of the older DLL with known security issues. I am afraid that's out of discussion.

[rbhanda]

Hello,
We have released an update to .NET 6.0 and .NET 7.0 to resolve this issue.

[NikolaMilosavljevic]

@czdietrich the issue seems to be resolved with updated release, mentioned above.