Runtime: Windows lies to dotnet.exe about the OS version

[peterhuene]

_From @heaths on January 26, 2019 23:13_

Steps to reproduce

On Windows 10:

1. mkdir test
2. cd test
3. dotnet new console
4. Change Program.cs to call Console.WriteLine(Environment.OSVersion.Version)
5. dotnet run

Expected behavior

See "10.0.17663" (for example, on RS5)

Actual behavior

See "6.2.9200.0"

This is because dotnet.exe's RT_MANIFEST resource is auto-generated with only the asInvoker privilege level, but is lacking the supportedOS. Instead, you should consider authoring a manifest like the following and adding it to your dotnet.csproj as the ApplicationManifest:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel level='asInvoker' uiAccess='false' />
            </requestedPrivileges>
        </security>
    </trustInfo>
    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
        <application>
            <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" />
            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />
            <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
            <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />
            <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
        </application>
    </compatibility>
</assembly>

This is problematic when running dotnet run with a console app that needs the correct Windows OS version, such as a benchmark application using BenchmarkDotNet.

Environment data

.NET Core SDK (reflecting any global.json):
Version: 2.1.503
Commit: 4c506e0f35

Runtime Environment:
OS Name: Windows
OS Version: 10.0.17763
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.503\

Host (useful for support):
Version: 2.1.7
Commit: cca5d72d48

.NET Core SDKs installed:
1.0.0-preview2-003121 [C:\Program Files\dotnet\sdk]
1.0.0-preview2-003131 [C:\Program Files\dotnet\sdk]
1.0.0-preview2-003156 [C:\Program Files\dotnet\sdk]
1.0.0-rc4-004771 [C:\Program Files\dotnet\sdk]
1.0.0 [C:\Program Files\dotnet\sdk]
1.0.2 [C:\Program Files\dotnet\sdk]
1.0.3 [C:\Program Files\dotnet\sdk]
1.0.4 [C:\Program Files\dotnet\sdk]
1.1.0 [C:\Program Files\dotnet\sdk]
2.0.0-preview2-006127 [C:\Program Files\dotnet\sdk]
2.0.0 [C:\Program Files\dotnet\sdk]
2.0.2 [C:\Program Files\dotnet\sdk]
2.0.3 [C:\Program Files\dotnet\sdk]
2.1.2 [C:\Program Files\dotnet\sdk]
2.1.4 [C:\Program Files\dotnet\sdk]
2.1.101 [C:\Program Files\dotnet\sdk]
2.1.103 [C:\Program Files\dotnet\sdk]
2.1.201 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.400 [C:\Program Files\dotnet\sdk]
2.1.401 [C:\Program Files\dotnet\sdk]
2.1.403 [C:\Program Files\dotnet\sdk]
2.1.500 [C:\Program Files\dotnet\sdk]
2.1.502 [C:\Program Files\dotnet\sdk]
2.1.503 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 1.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.0-preview2-25319-02 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.3-servicing-26724-03 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

_Copied from original issue: dotnet/cli#10660_

[peterhuene]

_From @heaths on January 26, 2019 23:35_

Based on dotnet/core-setup#3638 it looks like a decision was made to fix this for the dotnet CLI in the dotnet/core-setup project, though I'm not clear on the relationship of that with this CLI. The commit from dotnet --info above is found here in this dotnet/cli project.

[peterhuene]

Hi @heaths,

It's a tad bit confusing, but this repo is responsible for building dotnet.dll which implements the .NET Core SDK; technically the "CLI" interface, whereas the dotnet/sdk repo implements the MSBuild-side of the SDK. As you've already discovered, dotnet.exe (the native "muxer" responsible for finding and loading .NET Core SDKs) is actually built out of dotnet/core-setup and the issue you've linked to has been fixed for the current 3.0 preview SDK.

Would you mind trying this with the x64 3.0 preview SDK and see if the issue has been adequately resolved?

Thanks!

p.s. I remember you from the DevHood days, some 18 years ago, crazily enough!

[peterhuene]

_From @heaths on January 28, 2019 16:38_

I have that version currently installed on my other box and still seeing it. Seems everything is 3.0:

PS [00:00:01.687] C:\Users\heaths\AppData\Local\Temp\asdf
+> dotnet run --fx-version 3.0.0-preview-27122-01
Microsoft Windows NT 6.2.9200.0
PS [00:00:01.370] C:\Users\heaths\AppData\Local\Temp\asdf
+> gcm dotnet

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     dotnet.exe                                         3.0.271... C:\Program Files\dotnet\dotnet.exe

The source is the same as what I described in my repro.

"DevHood" - wow, I had completely forgotten about that. It's been a long time! :)

[peterhuene]

I have a later SDK installed (3.0.0-preview-27321-5) and I see the supportedOS elements in the manifest for the muxer (C:\Program Files\dotnet\dotnet.exe):

...
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"></supportedOS>
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"></supportedOS>
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"></supportedOS>
    </application>
  </compatibility>
...

However, I still get 6.2.9200.0 when running the example. Perhaps this is a corefx issue not calling the appropriate API?

[peterhuene]

_From @livarcocc on January 28, 2019 18:45_

Yes. Let's move the issue to corefx to be investigated there.

[peterhuene]

I forgot that we're actually activating through the apphost now. If you add <UseAppHost>false</UseAppHost> as a property in your .csproj, you'll get the correct version, which shows that when run via dotnet, the manifest is correct and corefx is doing the right thing.

The problem is the apphsot manifest, not dotnet's. I'm going to move this issue to dotnet/core-setup and we'll go from there.

[peterhuene]

The question then becomes: should the apphost also have the supportedOS elements in its manifest given that it's effectively for the user's application and would "ship" as third party?

[heaths]

Thanks. I can confirm using <UseAppHost>false</UseAppHost> works as expected.

[wjk]

My thoughts on the apphost manifest issue: Include the supportedOS elements in the apphost manifest by default, if and only if the developer does not supply a custom manifest. (If one is specified, then the default manifest will be overwritten; the onus is then on the developer to supply the appropriate supportedOS elements in their manifest.)

[vitek-karas]

The apphost has no manifest by default in it. This is intentional to make our SDK easier. It can blindly add stuff without worrying to remove existing resources.

Right now the C# build produces a manifest without supported versions, only the invoker stuff. And that's what gets inserted into apphost. The SDK basically blindly copies any native resource (including manifest) from the managed .dll to the apphost.exe.

Note that the current behavior is consistent with:

• Existing behavior of a new .NET Core 2.2 project and below
• Existing behavior of a new .NET Framework project on desktop
• Existing behavior of a new C++ project in VS

That doesn't mean it can't be changed though. I personally don't know. Having consistent behavior with everything else in VS is appealing, but on the other hand I can see why this is unexpected behavior on Win 10.
I'm actually not sure where the current manifest originates from. I think it's the C# compiler which autogenerates it. @peterhuene would you know?

[heaths]

I don't think its consistent with the .NET Framework if manifesting our managed EXE (as we do often for our bootstrappers / installers) with <supportedOS> works in those cases? But in Core, we don't have control over the application host EXE. And even with a new VC++ project, we can (and often do, as needed) commit an application manifest and override the default /MANIFEST* switches (or merge).

While I understand wanting to be consistent by default, right now we seem to have no ability to customize this behavior through well-documented and understood means.

[vitek-karas]

It is fully supported to customize the manifest. Add this property to your .csproj

<ApplicationManifest>app.manifest</ApplicationManifest>

The C# compiler will embed this in the managed .dll it compiles as a native resource (just like it does in .NET Framework for the managed .exe). And then .NET Core SDK will copy the native resource into the apphost, that is your app.exe.

Similarly you can specify icon, file versions and any other native Win32 resource.

Note that this behavior is new in .NET Core 3.0.

[heaths]

I tried that. It didn't work. See above. Not until I added the <UseAppHost>false</UseAppHost> property to my csproj.

[vitek-karas]

That is really weird.
I tried with a slightly newer build of SDK 3.0.100-preview-010184

dotnet new console
// add app.manifest with the content as above in this issue
// edit .csproj to add the ApplicationManifest element pointing to app.manifest
// edit the Program.cs to print out the OS version
dotnet run

Output:
10.0.17763.0

I though it made it into Preview 1, but it's possible it didn't. Can you try with latest build from dotnet/core-sdk?

[heaths]

That's working, yes. Being an internal dogfooder, I probably had some other earlier version. Thanks.

[peterhuene]

I think this can be closed as users would need to specify a custom manifest manually to make this scenario work with a .NET Framework application too, right?

However, I can acknowledge the confusion with regards to using dotnet run without an apphost or dotnet exec <application_dll> (which is what dotnet run will do internally without an apphost) causing different behavior because dotnet has its own manifest that enables the capabilities. I don't know of a good solution to that other than user education.

[vitek-karas]

I know the dotnet.exe behavior is slightly confusing... but this is probably the better way. We could leave it without manifest, but then if somebody did run a UI app with it, it may not even work that well.
Glad to hear it works with the apphost,