huoyaoyuan
commented
1 month ago How about registering AssemblyLoadContext.Resolving event?
Sharing the file layout may help diagnosing the issue.
Open yaakov-h opened 1 month ago
huoyaoyuan
commented
1 month ago How about registering AssemblyLoadContext.Resolving event?
Sharing the file layout may help diagnosing the issue.
yaakov-h
commented
1 month ago @huoyaoyuan that doesn't seem to affect it, I've tried using Load(name) and Assembly.LoadFrom(..) in that event and neither seem to have any effect.
For the file layout, in this repro:
C:\GIT\GITHUB\YAAKOV-H\DOTNET-REPRO-REMOTE-WEBADMIN\BIN
│ PluginHost.deps.json
│ PluginHost.dll
│ PluginHost.exe
│ PluginHost.pdb
│ PluginHost.runtimeconfig.json
│ PluginInterfaces.deps.json
│ PluginInterfaces.dll
│ PluginInterfaces.pdb
│
└───plugins
│ Microsoft.Web.Administration.dll
│ PluginInterfaces.dll
│ PluginInterfaces.pdb
│ RemoteWebAdministrationPlugin.deps.json
│ RemoteWebAdministrationPlugin.dll
│ RemoteWebAdministrationPlugin.pdb
│ RemoteWebAdministrationPlugin.runtimeconfig.json
│ System.Security.Permissions.dll
│ System.Windows.Extensions.dll
│
└───runtimes
└───win
└───lib
└───net8.0
System.Windows.Extensions.dllIn the real project, the plugin dir is not a subdir of the host program.
huoyaoyuan
commented
1 month ago I've tried using
Load(name)andAssembly.LoadFrom(..)in that event and neither seem to have any effect.
I believe AssemblyLoadContext.LoadFromAssemblyPath is the correct method - loading the assembly from given file, into the given ALC.
yaakov-h
commented
1 month ago Looking over the output, the Resolving event doesn't even get called in the first place.
yaakov-h
commented
1 month ago This also seems to affect loading System.ServiceProcess.ServiceController when touching the Application Pool APIs.
yaakov-h
commented
1 month ago I still don't understand why this is happening the way that it is, but as someone trying very explicitly to load a .NET Framework into .NET 8 this is the only workaround that seems to do the trick:
static MyPlugin()
{
AppDomain.CurrentDomain.AssemblyResolve += (sender, e) =>
{
if (e.Name.StartsWith("System.Security.Permissions,", StringComparison.Ordinal) || e.Name.StartsWith("System.ServiceProcess.ServiceController,", StringComparison.Ordinal))
{
var myPath = Path.GetDirectoryName(typeof(MyPlugin).Assembly.Location)!;
var assemblyPath = Path.Combine(myPath, new AssemblyName(e.Name).Name + ".dll");
return Assembly.LoadFrom(assemblyPath);
}
return null;
};
}
agocke
commented
4 weeks ago Hmm, not aware of any known issue that prevents this.
@elinor-fung any ideas?
Description
I need to remotely administer an IIS server, and Microsoft.Web.Administration is a long-standing solution which manages this via remote COM APIs.
The latest versions of Microsoft.Web.Administration ships for .NET Standard, but these builds have the remote-administration code compiled out, and instead just throw a
NullReferenceExceptionfromServerManager.OpenRemote.The older version 7.0 of Microsoft.Web.Administration only ships for .NET Framework 2.0, but it works on .NET 8 if we supply System.Security.Permissions as well via NuGet.
However, the .NET 8 runtime fails to load System.Security.Permissions when operating inside of another AssemblyLoadContext. It only seems to succeed if the entrypoint project is what takes on the package references.
When debugging this the runtime does not even ask for System.Security.Permissions.dll. I cannot find anything from a
dotnet-traceto explain why it is failing, and procmon64 suggests that the .NET Runtime does not even look for the file on disk, it just aborts early with an exception.Reproduction Steps
On a Windows machine with IIS and the .NET 8 SDK installed:
cd bin.\repro.ps1from PowerShell as Administrator (elevated)Expected behavior
The script displays success in all 5 scenarios:
Actual behavior
The first two scenarios fail, the final three pass:
Regression?
This worked using Assembly.Load in .NET Framework. likely due to System.Security.Permissions being part of the BCL.
Known Workarounds
Adding a direct reference from the plugin host to the plugin project seems to work as a workaround, though I have absolutely no idea why. This is also not a viable permanent/long term workaround, more of a strange oddity discovered whilst trying to reproduce the issue.
Additionally, using
AppDomain.CurrentDomain.AssemblyResolvehook as shown here appears to be a workaround, but this seems to break the purpose and spirit of usingAssemblyLoadContext.Configuration
dotnet --info:N.B. this also fails on machines w/o .NET 9 previews.
Other information
No response