Sdk: .NETCore apps cannot specify a Windows application manifest and other things that must go in exe

[ericstj]

dotnet.exe does not contain an application manifest, nor does the stripped down version when building a standalone app. The result is that applications cannot specify supportedOS to tell Windows they want to run without any OS version compat shims.

On desktop the way this works is that an application can add a manifest file to the app project (Add new item > Application manifest file) and that gets embedded in the exe by the compiler. Since .NETCore apps don't actually build the EXE we'd have to do something different.

I propose we change the host to include all the latest supportedOS entries at the time we ship. This is consistent with what we do for exe's in desktop. We could then allow the application to specify a manifest then the SDK could replace the one in the host when building a standalone app.

[livarcocc]

Is there an issue tracking this for the host side of the changes at core-setup? I imagine the SDK side would basically be able to respect this list and replace the manifest when appropriate?

[ericstj]

I opened an issue in core-setup.

I think the SDK side would be to support specification of an Application Manifest for selfcontained applications and replace the application manifest from the host with the one specified by the project. That seems to give the most parity with the desktop way of doing things.

[ericstj]

replace the application manifest from the host with the one specified by the project

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.

[ericstj]

This needs to be done for .NETCore 3.0. There are a lot of things that should be transferred from the app to the host in the case of a standalone app in order to meet people's expectations. Here's a partial list:

1. Sub system bit (EG: windows vs console).
2. Windows manifest
3. Version
4. Icon

1 & 2 will directly impact the desired functionality of .NET Core 3.0. There may be more. /cc @JeremyKuhne

[nguerrera]

@tannergooding Do you have a pointer to the work you started for at least (3) in list above?

[tannergooding]

@nguerrera, should be here: https://github.com/tannergooding/sdk/tree/embed-verinfo... I haven't checked if I have anything local that hasn't been pushed yet.

[nguerrera]

Broadened the title to include 1-4 and whatever else.

[nguerrera]

Subsystem bit is implemented now: #2470

[Pilchie]

@DustinCampbell and I were chatting about this this morning. In #2470, that only happens if there is a rid specified - should we do that implicitly and generate a host exe, etc if we know that it is a wpf/winforms exe (contains the framework reference)?

[livarcocc]

Should we imply the RID itself in this case? With a self-contained false? This behavior would follow from that.

And how would we choose between x86 and x64? I remember this being hard in the past when we were looking for some RID for compatibility for full framework projects.

[nguerrera]

@peterhuene and I were just chatting about this challenge as well, and there isn't an easy answer.

[nguerrera]

I think we should track whether you get an apphost by default separately from the work to put more stuff in an apphost.

[livarcocc]

I believe this is being addressed by dotnet/sdk#2545.

[sbomer]

Opened https://github.com/dotnet/sdk/issues/2553 to track the question about implicit RIDs and apphost generation.