Runtime revision version mismatch can cause broken application to be installed

[caesay]

When installing .net 5/6 applications, Squirrel will allow an application to be installed if the major version matches. Eg, using the --framework net6 argument, Squirrel only verifies that any version of net6 is installed (6.0.0, 6.0.1, etc).

If an application depends on a higher version (6.0.1) and a lower version is installed (6.0.0) this can produce extremely undesirable behaviour. The user does not even get the expected "Net 6 is not installed, click here to download" dialog, which is shown when no version of net6 is installed. Instead, the exe can just silently crash if they require code from the higher runtime version.

It will be important to support this properly to ensure people do not install broken applications.

One option is to require application authors to be extremely specific about what version the application is built for (eg --framework net602 instead of just --framework net6).

Another option might be using a tool like ildasm and reading the dll manifest references which are version specific. We could detect the highest required version and then automatically make sure it's lower to or equal to the installed runtime during setup. Possibly PeNet can read this manifest already rather than shipping another external tool. (edit: PeNet can load the CLR MetaData Tables and look at AssemblyRef, but only MajorVersion is shown on http://penet.io/ - need to have a look at code and see if we can get minor/revision too. ILSpy can show the full version, so presumably it's possible)

See more RandomEngy/VidCoder#979

This issue does not impact the full framework or vcredist as major/minor/revision versions are already considered there; this issue only impacts netcore3 and net5/6.

[caesay]

We now analyze dotnet binaries (except SingleFileBundles) and generate warnings if we believe that you're using the wrong framework. There are lots of checks and warnings to help you select the correct framework. This is done with no added external dependencies and has no impact to potential cross-platform developments in the future.

If you do not publish a self contained application and do not add a --framework argument, you may see a warning such as

[WARN] DotnetUtil: VidCoder.exe has 35 unresolved references, and no matching runtimes were found. (Are you missing the '--framework net6.0' argument?)

If you specify a --framework argument that was not found (in this example, net6.1) you'll see an error that the framework could not be found - but the release build will continue. It allows the package to be built anyway so that package creation can be done when there is no internet and the version can not be verified (we look this up online rather than hard-coding)

[ERRO] Runtimes: Unable to verify version for runtime 'net6.1': System.Exception: Dotnet version '6.1' (WindowsDesktop) was not found online or could not be retrieved.
---> System.Net.Http.HttpRequestException: Response status code does not indicate success: 404 (The specified blob does not exist.).

If you specify a --framework argument with a major.minor version that matches a valid online dotnet version, but your build version is higher than the latest online it will throw an error and fail the build

[ERRO] System.Exception: For runtime string 'net6.0.5', version provided (6.0.5) is greater than the latest available version (6.0.2).

If you specify a --framework argument (eg. net6.0) that is lower than what your app depends on (in this case, net6.0.2), you'll see the following warning:

[WARN] DotnetUtil: VidCoder.exe references PresentationCore,Version=6.0.2.0 - which is higher than the current runtime version (6.0).
[WARN] DotnetUtil: VidCoder.exe references PresentationFramework,Version=6.0.2.0 - which is higher than the current runtime version (6.0).
[WARN] DotnetUtil: VidCoder.exe references WindowsBase,Version=6.0.2.0 - which is higher than the current runtime version (6.0).
[WARN] DotnetUtil: VidCoder.exe references System.Xaml,Version=6.0.2.0 - which is higher than the current runtime version (6.0).
[WARN] DotnetUtil: VidCoder.exe references System.Windows.Forms,Version=6.0.2.0 - which is higher than the current runtime version (6.0).

All of this is designed to help you select the correct dotnet --framework but ultimately tries to not force anything on you. All of this is now also forward-compatible, so since we are using dotnet api's, changes will not be needed to support future versions of dotnet (eg. 6.1, 7.0, and so forth).

[caesay]

This has been released in 2.8.1-pre.

[RandomEngy]

Perfect! Thanks for this fix.

[caesay]

This is a bug in the SDK, see

• 6.0.2 SDK update has broken WinForms apps dotnet/winforms#6663
• Issue building with Windows Desktop 6.0.2 dotnet/wpf#6109
• Issue building with Windows Desktop 6.0.2 dotnet/core#7176

the changes here should not be needed for future versions of the SDK.