Host should add supportedOs to application manifest to avoid shims from the Windows OS - Windows only

[ericstj]

See dotnet/sdk#1899.

Essentially we should add a application manifest file to dotnet.exe with all the known supportedOs entries.

[steveharter]

Setting 3.0 per last comment in dotnet/sdk#1899 per this:

I looked at this a bit more and I'm going to double down on this recommendation. That manifest can contain a lot of things that are application specific that folks may depend on which we cannot get right in a single copy in dotnet.exe."

[vitek-karas]

@ericstj Since dotnet/sdk#2545 basically solved this for apphost (app which have their own .exe), do you think that it's now done?
I know there's a discussion of modifying the context at runtime for the dotnet.exe as well, but I don't think that's what this issue is about.

[ericstj]

Not every application runs with its own exe, what about for the application launched with dotnet foo.dll or for the dotnet commands?

In the case of desktop Exe's and tools we always added the supportedOs entries so the tools wouldn't get app-compat shims by default.

[jkotas]

what about for the application launched with dotnet foo.dll or for the dotnet commands?

Can we do nothing until we get feedback this needs to be fixed? Whatever we do here will always be imperfect. There are way too many things in the classic Win32 that depend on your .exe identity.

I think we should make the story simple and always use apphost .exe for the Windows-specific apps.

[ericstj]

I see this issue as less about the Windows-specific app decision and more about what should the default behavior be for dotnet.exe. I opened this issue merely to address supportedOS entries for the host so that it doesn't get Windows-XP compat shims as it does today. That could be relevant for x-plat applications as well. I'm not sure we'll get feedback on this since the behavior of these version lie shims can be very subtle and folks might write it off or work around it. I suspect the Windows folks would have an opinion if we told them that all .NETCore applications were being treated as XP applications.

[jkotas]

more about what should the default behavior be for dotnet.exe.

It should be "latest known OS". We have fixed that already, no?

[ericstj]

We have fixed that already, no?

Not in the latest dotnet.exe that I downloaded. If you do, then please close this issue. I only meant for this issue to track a fix to the avoiding the version-lie shims for dotnet.exe-based apps.

[vitek-karas]

Modified the title to better match the desired behavior.
Marked as Windows-only for now.
@ericstj - do you know if there are similar things for Mac or Linux?

[ericstj]

My understanding is that Mac/Linux haven't invested this much in appcompat but I don't know what I don't know. I did a quick web search and didn't see anything. @stephentoub or @janvorli might know if there's anything similar in the binary format for unix executables that communicates the compatibility of the app.

[jkotas]

@ericstj Could you please share the repro steps w/ the expected and actual behavior to demonstrate the issue you think needs fixing? I am not able to find the compat in a simple hello world.

[ericstj]

Here is a sample. You can build that and run the desktop version and the core version and observe the difference.

C:\repros\CheckOS>dotnet bin\Debug\netcoreapp2.1\CheckOS.dll
Older than 7.0.0

C:\repros\CheckOS>bin\Debug\net471\CheckOS.exe
Equal or newer than 7.0.0

[jkotas]

Ok, this needs to be fixed in: https://github.com/dotnet/core-setup/blob/master/src/corehost/cli/dotnet/CMakeLists.txt

Also, I have noticed that apphost with standalone publish has two manifests now:

We should fix https://github.com/dotnet/core-setup/blob/master/src/corehost/cli/apphost/CMakeLists.txt to not have any manifest at all, so the one copied from the managed .dll is the only one there.

[ericstj]

@jkotas is there an issue tracking that?

Nevermind, I see @vitek-karas fixed it.