You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a managed component AssemblyDependencyResolver which is implemented by PInvoking into hostpolicy. Since in the new single-file the hostpolicy doesn't exist as a separate module, we need to redirect the PInvokes to the main module, just like we do for other statically linked libraries.
Note that this needs to work on Windows as well - which is different from the case we already implement which is Linux only.
Run as a single-file self-contained console app. i.e. dotnet publish -r win-x64 /p:PublishSingleFile=true. The result is:
Unhandled exception. System.InvalidOperationException: Cannot load hostpolicy library. AssemblyDependencyResolver is currently only supported if the runtime is hosted through hostpolicy library.
---> System.DllNotFoundException: Dll was not found.
at Interop.HostPolicy.corehost_set_error_writer(IntPtr errorWriter)
at System.Runtime.Loader.AssemblyDependencyResolver..ctor(String componentAssemblyPath)
It will work if published as FDD single-file i.e. dotnet publish -r win-x64 --self-contained false /p:PublishSingleFile=true - this will now fail with error about not finding path.dll.
I verified that it behaves the same on Linux with the latest RC from installers.
The text was updated successfully, but these errors were encountered:
On Linux this is relatively simple - just add libhostpolicy to the list of "Special" libraries in dllimport.cpp
On Windows this a bit more tricky:
We need to special case hostpolicy.dll in dllimport.cpp as well, but only when running with single-file host with hostpolicy included
The coreclr itself can't tell if single-file host has been used which has hostpolicy linked in. The best solution is to pass a new property from hostpolicy to runtime upon init and remember this in the runtime. One day when we switch to using superhost on Windows as well, this could go away.
I got it working in a hacky way on Windows as a proof of concept (the special cased library returns WszGetModuleHandle(NULL) as the handle to the executable). But then it showed more issues in hostpolicy, so AssemblyDependencyResolver is still broken. I'm looking into the hostpolicy code some more, there are likely additional changes necessary.
There's a managed component
AssemblyDependencyResolver
which is implemented by PInvoking intohostpolicy
. Since in the new single-file thehostpolicy
doesn't exist as a separate module, we need to redirect the PInvokes to the main module, just like we do for other statically linked libraries.Note that this needs to work on Windows as well - which is different from the case we already implement which is Linux only.
Repro:
Run as a single-file self-contained console app. i.e.
dotnet publish -r win-x64 /p:PublishSingleFile=true
. The result is:It will work if published as FDD single-file i.e.
dotnet publish -r win-x64 --self-contained false /p:PublishSingleFile=true
- this will now fail with error about not findingpath.dll
.I verified that it behaves the same on Linux with the latest RC from installers.
The text was updated successfully, but these errors were encountered: