Add ability to output a shim .exe + .dll for an application (for WinRT activation)

[Sergio0694]

Overview

We're working on enabling more scenarios on modern .NET for WinRT applications (WinUI 3, UWP). One such scenario involves applications that reference one or more WinRT components, and need to both be executed (as an app), as well as act as the implementation binary for those (merged) WinRT components.

To make this clearer, consider this scenario:

• You have a WinUI 3 (or UWP) application
• You reference MyComponent.csproj, which is a WinRT component. Common scenarios:
  • Out-of-proc background tasks, ie. exporting IBackgroundTask types
  • Custom video effects, ie. exporting IBasicVideoEffect types

When publishing your app, you need two different binaries being produced:

• A .dll with all the code of your published project (and referenced projects, including those WinRT components)
• A stub .exe, which simply invokes a private Main from that .dll

This is because there's multiple activation paths for your app:

• When launched (eg. by the user, or by the OS), that .exe will be run
• When used as a WinRT component, that .dll will be loaded directly

To make this all work, we need two features:

• Merging and exporting all WinRT activation factories by all referenced WinRT component projects
  • We're adding support for this in WinRT here
• A way to publish as this ".dll + stub .exe" combination

The latter is described in more detail in this .NET Native blog post:

We basically need to match this for modern .NET as well.

Proposal

Talking with @MichalStrehovsky about this, he suggested we might add some UseShimExe property, which would make the build produce these two components. Ideally, this would also make things work as expected when using CoreCLR, and not just NativeAOT.

Internal tracking item (MSFT only): microsoft/OS/48896901.

Alternatives

We could do this entirely from the CsWinRT side (adding some source generator to produce a new [UnmanagedCallersOnly] method to invoke the user-defined entry point, and then bundle some native host to act as stub .exe, which we could copy to the output folder). The main issues with this approach though are that we'd need to ask users to mark their applications as using a library output type, which is very confusing and counter-intuitive, and that it's not entirely clear how we'd also make this work for CoreCLR.

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[AaronRobinsonMSFT]

/cc @elinor-fung

[AaronRobinsonMSFT]

This doesn't seem like it has much utility beyond a WinRT activation scenario and appears to be a typical AppHost scenario. What is the difference here?

[Sergio0694]

So, there would basically be two different behaviors here depending on CoreCLR vs NativeAOT:

• CoreCLR: (quoting @jkoritzinsky): "the .dll would also be native, and it would be the place that calls the runtime and sets up the process using the nethost APIs. The .exe would just call the native .dll". That native .dll would also need to export all [UnmanagedCallersOnly] methods declared in the application project being compiled (just that one .csproj, as usual).
• NativeAOT: the application would be compiled into a .dll instead of an .exe, and a thin stub .exe would also be included in the output folder, just jumping into a generated export from that .dll. I'd assume this stub .exe could be the same as the one used in the CoreCLR scenario (we could just use the same name for the "secret" Main entry point being exported by the .dll).

[Sergio0694]

"doesn't seem like it has much utility beyond a WinRT activation scenario"

At least in theory, this can also be used whenever someone has some shared logic used by their app that they also want to expose in some other way (eg. library native with whatever ABI, be it WinRT, COM or whatever). Using this approach they can compile everything into a single .dll and not bloat their binary size with basically two copies of all the shared code (plus two copies of the whole runtime/GC, at least in the NativeAOT case).

[jkotas]

The main issues with this approach though are that we'd need to ask users to mark their applications as using a library output type, which is very confusing and counter-intuitive

We had similar problem with iOS apps and NativeAOT. iOS apps have Main method, but they want to be published as special native libraries because of how the app model is put together. We have introduced CustomNativeMain property to make this mode possible in the .NET SDK and left all the heavy lifting (compiling the actual native libraries, etc.) for Xamarin SDK. Can we do the same here - generalize the existing solution used for iOS apps?

[Sergio0694]

I remember Jeremy also mentioning that feature and suggesting we might be able to perhaps reuse it here too. Just so I understand, what part of the work would you imagine this generalized version of that feature would handle? Eg. would the shim .exe also be produced by the runtime/SDK, or would that have to be bundled by something else (eg. CsWinRT)? Another question I have is, how do you imagine the CoreCLR scenario would work? It seems to me that that would essentially have to be some combination of a shim .exe + basically DNNE (host + exports forwarder) + managed .dll(s)..?

Just trying to understand how the various pieces would be structured and fit together here 😅

[jkotas]

would the shim .exe also be produced by the runtime/SDK, or would that have to be bundled by something else (eg. CsWinRT)?

I expect that the .NET SDK would just do the minimum to get out of the way. It would be up to the app model specific SDK (e.g. CsWinRT) to produce the custom host and shim. It is how the current solution for iOS works.

[Sergio0694]

So like, on NativeAOT, the main difference between a fully undocked approach and this would be:

• No need to remove the OutputType=Exe
• The output would be a .dll and not an exe
• This .dll would also have this export with some well known name, that forwards to the real entry point of the "original" .exe (?)

Is the above correct, on NativeAOT? And how would things look like with CoreCLR? Would the output still be a .dll (though managed), and that export be..?

[MichalStrehovsky]

If we do this the same as iOS/Xamarin, it would mean that OutputType can stay Exe and CsWinRT would need to take the responsibility of what to do with the object file generated by ilc (native AOT targets would not run the linker to generate the EXE). CsWinRT would have to generate whatever other glue is needed (something that initializes the runtime) and invoke link.exe to create the final executable (which would be a DLL, even though OutputType is EXE). Then it would also have to create the shim EXE and ensure it all gets published.

We don't currently have the same separation of linker arguments on Windows that we have on iDevices, so we'd need to introduce the same protocol (discussed around #88294 (comment)).