plugins fail to load for dotnet 6 single file - self contained app

[freddyrios]

Description

Running plugins with dotnet 6 rc1 for single file, self contained applications broke. The issue was found originally in Linux, but was also reproduced on windows. Specifically the AssemblyDependencyResolver's constructor throws an exception when loading the plugin.

To reproduce follow the instructions on the readme in this isolated reproduction of the issue: https://github.com/freddyrios/pluginsloadfailure.

Alternatively follow microsoft documentation on creating an application with plugins https://docs.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support and publish it as a single file, self contained app with the runtime identifier that matches your system.

Configuration

dotnet --version: 6.0.100-rc.1.21463.6
reproduced both on windows 10 and raspbian (linux / debian)
windows 10 was x64 and raspbian is arm
doesn't look specific to the OS or architecture

Regression?

It is a regression, see the demo which shows doing the same steps with a different target breaks.

Other information

This is the stacktrace:

System.InvalidOperationException: Cannot load hostpolicy library. AssemblyDependencyResolver is currently only supported if the runtime is hosted through hostpolicy library.
---> System.EntryPointNotFoundException: Entry point was not found.
at Interop.HostPolicy.corehost_set_error_writer(IntPtr errorWriter)
at System.Runtime.Loader.AssemblyDependencyResolver..ctor(String componentAssemblyPath)
--- End of inner exception stack trace ---
at System.Runtime.Loader.AssemblyDependencyResolver..ctor(String componeyntAssemblyPath)
at AppWithPlugin.PluginLoadContext..ctor(String pluginPath) in [redacted]\pluginsloadfailure\AppWithPlugin\PluginLoadContext.cs:line 13
at AppWithPlugin.Program.LoadPlugin(String relativePath) in [redacted]\pluginsloadfailure\AppWithPlugin\Program.cs:line 71
at AppWithPlugin.Program.<>c.

b__0_0(String pluginPath) in [redacted]\pluginsloadfailure\AppWithPlugin\Program.cs:line 29
at System.Linq.Enumerable.SelectManySingleSelectorIterator`2.ToList()
at AppWithPlugin.Program.Main(String[] args) in [redacted]\pluginsloadfailure\AppWithPlugin\Program.cs:line 16

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

Issue Details

---

Description

Running plugins with dotnet 6 rc1 for single file, self contained applications broke. The issue was found originally in Linux, but was also reproduced on windows. Specifically the AssemblyDependencyResolver's constructor throws an exception when loading the plugin.

To reproduce follow the instructions on the readme in this isolated reproduction of the issue: https://github.com/freddyrios/pluginsloadfailure.

Alternatively follow microsoft documentation on creating an application with plugins https://docs.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support and publish it as a single file, self contained app with the runtime identifier that matches your system.

Configuration

dotnet --version: 6.0.100-rc.1.21463.6
reproduced both on windows 10 and raspbian (linux / debian)
windows 10 was x64 and raspbian is arm
doesn't look specific to the OS or architecture

Regression?

It is a regression, see the demo which shows doing the same steps with a different target breaks.

Other information

This is the stacktrace:

System.InvalidOperationException: Cannot load hostpolicy library. AssemblyDependencyResolver is currently only supported if the runtime is hosted through hostpolicy library.
---> System.EntryPointNotFoundException: Entry point was not found.
at Interop.HostPolicy.corehost_set_error_writer(IntPtr errorWriter)
at System.Runtime.Loader.AssemblyDependencyResolver..ctor(String componentAssemblyPath)
--- End of inner exception stack trace ---
at System.Runtime.Loader.AssemblyDependencyResolver..ctor(String componeyntAssemblyPath)
at AppWithPlugin.PluginLoadContext..ctor(String pluginPath) in [redacted]\pluginsloadfailure\AppWithPlugin\PluginLoadContext.cs:line 13
at AppWithPlugin.Program.LoadPlugin(String relativePath) in [redacted]\pluginsloadfailure\AppWithPlugin\Program.cs:line 71
at AppWithPlugin.Program.<>c.

b__0_0(String pluginPath) in [redacted]\pluginsloadfailure\AppWithPlugin\Program.cs:line 29
at System.Linq.Enumerable.SelectManySingleSelectorIterator`2.ToList()
at AppWithPlugin.Program.Main(String[] args) in [redacted]\pluginsloadfailure\AppWithPlugin\Program.cs:line 16

Author:	freddyrios
Assignees:	-
Labels:	area-Single-File, untriaged
Milestone:	-

[vitek-karas]

As far as I can tell it's a "regression" in single-file - specifically when hostpolicy is part of the apphost, which is true for any superhost.

It works a non-single-file SCD app just fine.
My guess - the PInvoke redirection doesn't kick in for hostpolicy - don't know why.

[freddyrios]

@vitek-karas yes, it is only a regression when making it a single file + self contained app.

Making it non single file or non self contained works.

[freddyrios]

@vitek-karas forgot to add, that's what we have been running with .net 5.

[vitek-karas]

I'm actually surprised that it worked on .net 5 - I would expect this to break even on .net 5 (windows or not)

[vitek-karas]

It does indeed work on .net 5 - interesting...

The theory is that in both cases the hostpolicy is part of the host/superhost, and since it seems the DllImport fails, it's probably because we don't correctly "Redirect" the PInvoke "inside".

This was the case already in .NET 5, but maybe something else changed.

This will be much easier to solve for @VSadov because he knows exactly how this works...