.NET SDK vs RT Compatibility issue/question

[JensNordenbro]

Imaging the following scenario:

On device on factory floor: I install windowsdesktop-runtime-6.0.0-win-x64.msi on a Windows 10 machine that is not configured to receive updates. No Internet available.

On my dev-machine:

Much later (years) I install the latest 100-series SDK (the initially used series), namely dotnet-sdk-6.0.126-win-x64.zip and I publish an empty (dotnet new winform) app as FWD (Framework dependent deployment).

I push this app to the Windows 10 machine on the factory floor.

• This app will not start. No error messages, no nothing.

When I read up on the compatibility in the documentation I would expect this to work since Major.Minor is fine and also I have stayed at the latest feature band for SDK to avoid feature incompatibilities, however it does not.

• Now I suspect I need to have Windows Update configured on the initially mentioned Windows 10 machine.

What say you on this topic?

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[vitek-karas]

It's hard to tell what's wrong. It is strange that you don't see any feedback about it not working. If this is a versioning problem I would expect:

• A console app should print out the error into the stderr
• GUI app should pop-up a dialog with the error

How do you start the app?

• app.exe or dotnet app.dll?

What is in the app.runtimeconfig.json in the built app which doesn't work?

Can you look into Event Log, most failures should be logged there.

[JensNordenbro]

app.exe

I can do it again tomorrow or you can repro. Since I only use standard dotnet new winforms and no code added you can try it easilly.

[JensNordenbro]

2 event log items @vitek-karas :

Application: Project1.exe CoreCLR Version: 6.0.121.56705 .NET Version: 6.0.1 Description: The process was terminated due to an unhandled exception. Exception Info: System.TypeInitializationException: The type initializer for 'Neo.ApplicationFramework.Common.Utilities.ProcessExplorer' threw an exception. ---> System.IO.FileLoadException: Could not load file or assembly 'System.Windows.Forms, Version=6.0.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The located assembly's manifest definition does not match the assembly reference. (0x80131040) File name: 'System.Windows.Forms, Version=6.0.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' at Neo.ApplicationFramework.Common.Utilities.ProcessExplorer.() at Neo.ApplicationFramework.Common.Utilities.ProcessExplorer..cctor() --- End of inner exception stack trace --- at Neo.ApplicationFramework.Generated.Globals.Main(String[] args) in C:\Users\WDAGUtilityAccount\Documents\iX Developer Falcon Projects\Project1\Generated\BuildFiles\Project1.cs:line 266

and then

Faulting application name: Project1.exe, version: 2.51.12568.0, time stamp: 0x63ed8286 Faulting module name: KERNELBASE.dll, version: 10.0.22621.3085, time stamp: 0x98257e11 Exception code: 0xe0434352 Fault offset: 0x0000000000064d8c Faulting process id: 0x0x1A4C Faulting application start time: 0x0x1DA5B2D9C416C1D Faulting application path: C:\Users\WDAGUtilityAccount\Documents\iX Developer Falcon Projects\Project1\Generated\bin\Release\net6.0-windows\win-x64\Project1.exe Faulting module path: C:\Windows\System32\KERNELBASE.dll Report Id: 50849514-b593-4754-afbd-4e8a82ff8168 Faulting package full name: Faulting package-relative application ID:

[vitek-karas]

Thanks for the information.

The short version: Building a winforms app targeting net6.0 using any of the up-to-date SDKs (so latest 6.0 SDK, or latest 8.0 SDK) produces an application which has an assembly reference to System.Windows.Forms, Version=6.0.2.0 - so not the baseline 6.0.0.0 version. Such an app won't run on old versions of the 6.0 runtime, because it requires a higher version of the assembly than what the runtime can provide.

This is made "weirder" by the fact that it still declares a framework dependency for version 6.0.0, so the app doesn't fail during framework resolution, but later on at runtime - which makes the error experience (out of the box) worse.

So for me the core question is - is it intentional that we update the version of ref assemblies in a patch release? As this causes the above problem to happen at runtime.

[vitek-karas]

Removing the area-host, but I don't know what is the right area - this is a servicing/refpack question.

[JensNordenbro]

The SDK 200 feature band seemed to be disbanded at some point (So strange...). Maybe that is related however this in mind breaks the promise of Major.Minor unless Windows Update is used in symmetry between dev computer and target device.

[JensNordenbro]

Any comments on this issue?