Self-contained WinRT components don't work.

[jlaanstra]

Describe the bug
WinRT.Host.dll doesn't work for a self-contained deployment. It requires .NET to be installed on the machine separately which can't be done with MSIX.

To Reproduce

1. Modify the BgTaskComponent sample to deploy the WPF App as self-contained by adding true
2. Deploy the package to a machine that doesn't have .NET framework packages installed.

Expected behavior
Toast task from the sample should work.

Actual behavior
Toast task does not work.

Version Info
CsWinRT 1.5.0

Additional context
N/A

[AaronRobinsonMSFT]

This is a blocking issue that, as currently implemented, is not possible with the WinRT.Host. The root cause is use of the hostfxr_initialize_for_runtime_config API, which doesn't support a self-contained scenario. In order to support a self-contained scenario the hostfxr_initialize_for_dotnet_command_line API needs to be used. However, using this API and enabling self-contained library is not without concerns.

1. The self-contained scenario is intentionally blocked for non-applications due concerns about enabling SxS in-proc versions of coreclr—which is not supported. Care must be taken to ensure the process that is loading the library will not be used by any other .NET library and inadvertently load another coreclr instance.

2. There is no direct support in the .NET SDK for creating a self-contained library. This is by-design and related to concern (1).

3. Using hostfxr_initialize_for_dotnet_command_line and then relying on hdt_load_assembly_and_get_function_pointer should be considered an anti-pattern for what users would desire. The issue has to do with which AssemblyLoadContext (ALC) the entry point assembly will be loaded into. Using hdt_load_assembly_and_get_function_pointer, the assembly maybe loaded again into a new isolated ALC as opposed to using the existing loaded instance in the default ALC. This has broad ramifications that need to be considered. Alternatively, in .NET 6 the hdt_get_function_pointer can be used which can load from the default ALC.

4. It isn't clear how servicing is to be performed for applications or services. There are various security patching processes that will be ignorant of self-contained applications and if the service is running in a sensitive environment, this is a real concern.

/cc @vitek-karas @elinor-fung @agocke

[jlaanstra]

1. The self-contained scenario is intentionally blocked for non-applications due concerns about enabling SxS in-proc versions of coreclr—which is not supported. Care must be taken to ensure the process that is loading the library will not be used by any other .NET library and inadvertently load another coreclr instance.

This should be easy to guarantee for packaged apps.

4. It isn't clear how servicing is to be performed for applications or services. There are various security patching processes that will be ignorant of self-contained applications and if the service is running in a sensitive environment, this is a real concern.

MSIX packaged apps are all self-contained (no other ways to guarantee .NET is on the machine), so this isn't a new concern for a self-contained WinRT component right?

[AaronRobinsonMSFT]

MSIX packaged apps are all self-contained (no other ways to guarantee .NET is on the machine), so this isn't a new concern for a self-contained WinRT component right?

That is predicated that CsWinRT is only targeting MSIX scenarios. From my understanding, CsWinRT doesn't require a packaged installation so the general concept should be factored into the cost of support and document how one handles servicing .NET assets.

[jlaanstra]

MSIX packaged apps are all self-contained (no other ways to guarantee .NET is on the machine), so this isn't a new concern for a self-contained WinRT component right?

That is predicated that CsWinRT is only targeting MSIX scenarios. From my understanding, CsWinRT doesn't require a packaged installation so the general concept should be factored into the cost of support and document how one handles servicing .NET assets.

Indeed CsWinRT doesn't require a packaged installation, but at the same time it currently doesn't block self-contained MSIX deployment and so I don't see any net-new concerns by allowing it for a WinRT component.

[jlaanstra]

An example of using https://github.com/AaronRobinsonMSFT/DNNE for self-contained components is here, in the NativeHost project of src/Samples/BgTaskComponent/BgTaskComponent.sln: https://github.com/jlaanstra/CsWinRT/tree/user/jlaans/self-contained

[angelazhangmsft]

An example of using https://github.com/AaronRobinsonMSFT/DNNE for self-contained components is here, in the NativeHost project of src/Samples/BgTaskComponent/BgTaskComponent.sln: https://github.com/jlaanstra/CsWinRT/tree/user/jlaans/self-contained

@jlaanstra @AaronRobinsonMSFT - to clarify, is there a way to implement self-contained C# WinRT components, or is further work in CsWinRT required for that support?

[AaronRobinsonMSFT]

or is further work in CsWinRT required for that support?

More work is needed. @jlaanstra was able to create a host that supports self-contained using DNNE but the built-in one needs to be updated to support the scenario. It is up to C#/WinRT to determine if self-contained is needed or not. There are UX and scenario limitations that need to be understood before officially supporting it.

[angelazhangmsft]

Thanks @AaronRobinsonMSFT.

I've opened https://task.ms/39162576 to track this

[JohnMcPMS]

I'm trying to author a component (.NET 6) that will be consumed by:

1. A packaged C++ process
2. A packaged C# process (different package)
3. A PowerShell module

This issue has me worried that my packaged scenarios won't work without .NET 6 being installed. Given that these scenarios revolve around installation/setup of systems, there is a very real possibility of it not being present.

Am I understanding it correctly?

Fortunately, I think we could bootstrap ourselves if needed, but I don't want for that to be a requirement if possible (it may even be explicitly blocked from being one).