Runtime: System.Runtime.Loader not copied to output directory

Created on 12 Jul 2017  路  36Comments  路  Source: dotnet/runtime

Hi,

I'm using 2.0.0-preview1-25305-02 and I have an issue with mixed netstandard and net462 projects in the same solution. Not sure if I'm doing something wrong or if there's something else.

I have a net462 app that loads another net462 dll containing some Unity hosting code. That in turn loads some other dlls, some of which are netstandard2.

On app startup I'm getting:

---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime.Loader, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

I had thought this was part of netstandard, but either way I've added it as a NuGet package dependency to the Unity project (seeing as that's the one that does dynamic loading), but for some reason it's not ending up in either the Unity project bin folder or the exe one. Do you know why this dll is not being deployed to the bin folder?

Thanks,
Ben Young

area-System.Runtime question untriaged

Most helpful comment

any resolution to this?

All 36 comments

The Fusion log looks like

=== Pre-bind state information ===
LOG: DisplayName = System.Runtime.Loader, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///F:/Dev/.../src/Examples/ExampleHost/bin/Debug/net462/
LOG: Initial PrivatePath = NULL
Calling assembly : FIS.Risk.Core, Version=0.1.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: F:\Dev\...\src\Examples\ExampleHost\bin\Debug\net462\FIS.Risk.Core.ExampleHost.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: System.Runtime.Loader, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
LOG: Attempting download of new URL file:///F:/Dev/.../src/Examples/ExampleHost/bin/Debug/net462/System.Runtime.Loader.DLL.
LOG: Attempting download of new URL file:///F:/Dev/.../src/Examples/ExampleHost/bin/Debug/net462/System.Runtime.Loader/System.Runtime.Loader.DLL.
LOG: Attempting download of new URL file:///F:/Dev/.../src/Examples/ExampleHost/bin/Debug/net462/System.Runtime.Loader.EXE.
LOG: Attempting download of new URL file:///F:/Dev/.../src/Examples/ExampleHost/bin/Debug/net462/System.Runtime.Loader/System.Runtime.Loader.EXE.

I'm interested, running into a similar issue with NUnit.Xamarin too on monoandroid71.

If I drop in a dll from C:\Program Files\dotnet\sdk\NuGetFallbackFolder\system.runtime.loader\4.3.0\lib\netstandard1.5 then I get:

Resolving FIS.Risk.Core.Logging.NullLogger,(none) (mapped from FIS.Risk.Core.Logging.ILogging, (none))
---> System.IO.FileLoadException: Could not load file or assembly 'System.Runtime.Loader, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

If I drop in from C:\Program Files\dotnet\sdk\NuGetFallbackFolder\system.runtime.loader\4.0.0\lib\netstandard1.5 then I get:

Resolving FIS.Risk.Core.Logging.NullLogger,(none) (mapped from FIS.Risk.Core.Logging.ILogging, (none))
---> System.TypeLoadException: Could not load type 'System.Runtime.Loader.AssemblyLoadContext' from assembly 'System.Runtime.Loader, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

hey @bencyoung , have you tried this again with netcoreapp/netstandard 2.0? I ask because we added some tooling fixes that would add a reference to a compatibility package that will make referencing net461 dependencies work, so I wonder of that fixes your problem. Let me know if you still see the issue.

I'm still getting the issue unfortunately.

A problem occurred when trying to run the application.: System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime.Loader, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Runtime.Loader, Version=4.0.0.0, Culture=neutral,...'
   at FIS.Risk.Core.Hosting.ComponentRunner.RunnerState..ctor(IReadOnlyList`1 args, IComponent component, Action hostingStop, Action hostingRestart, TimeSpan joinWait)
   at FIS.Risk.Core.Hosting.ComponentRunner.RunAsConsole(IReadOnlyList`1 args)

The version of System.Runtime.Loader that's ending up in the bin folder is:

image

Here's a minimal reproduction

BugDemo.zip

Running into the same issue with loader 4.3.0 even if I do copy the dll itself to the output folder before running.

Same issue with System.Runtime.Loader 4.3.0 and net471.
UPD. Found this https://github.com/dotnet/cli/issues/6019

Having the exact same issue, something is definitely wrong here. Side by side .netcore 2/4.7.1/.NET Standard 2 and System.Runtime.Loader is never copied. Blows up standard dependency injection code using AssemblyLoadContext

any resolution to this?

Asking if there's any resolution to this.

I am facing the same issue with .Net framework 4.6.1 with some reference to .Net Standard 2.0 libraries.
Please share workaround or resolution to this.

@nikunjratanpara When using the full framework, I went back to the traditional 'Assembly.Load' methods. Very unfortunate, but not way around this as we speak.

The only way I was able to get around this was to target both net471 and netstandard2.0. The resulting binaries generated for net471 includes Grpc.Core.dll that is the net45 version.

I also encountered this. My net471 application uses a netstandard20 project, which references System.Runtime.Loader. No warnings from nuget or build, but the DLL fails to load when needed at runtime - I can confirm that the DLL is missing in bin folder.

If System.Runtime.Loader is not supposed to be supported on .NET Framework, this really needs to be dealt with in a better way.

We haven't been able to repro this so if somebody can provide a small repro solution that would be ideal.

Here's a simple repro.
Repro.zip

I see I understand the scenario now, thanks for providing a repro. The problem is that System.Runtime.Loader is not supported on .NET Framework, this is a package that will only work on .NETCore App and UAP. We used to rely on a NuGet feature that wouldn't let this package install when targeting .NET Framework so you would get errors about this at compile time, but they changed this feature and now permit you to install the package and compile, so you now hit the error at runtime which is less than ideal. We could consider building a new version of this package that better stated that it is not supported on .NET Framework so that the incompatibility is found at compile-time.

Feel free to log an issue if you think it would be valuable to service the package.

cc: @ericstj as FYI.

I am also getting this issue - I have a .net Standard package and I'm using .net Framework test project to test the code. How do I work around this (without changing my .net Standard code)??

as said in this comment unfortunately there is no way of getting System.Runtime.Loader to work on .NET Framework. It is just not available there.

I've added this code as a work around:

if NETCOREAPP2_0 || NETCOREAPP2_1

        AssemblyLoadContext.Default.Unloading += (ctx) => ProcessStop();

endif

This allows the code above to execute only when running via a dotnet core app.

@joperezr, I don't really understand the motivation behind targeting System.Runtime.Loader pack to netstandard. This allows me to install this pack into netstandard project, that can be further consumed by netframework application without any compilation warnings/error, but it will eventually fail during runtime. If it works just on netcore and UAP, than I guess it should target just those platforms.

Here's some more background info from similar issues that should help illustrate the motivation with "jagged support" for packages.
https://github.com/dotnet/corefx/issues/11023#issuecomment-244131549
https://github.com/dotnet/corefx/issues/29365

Note that we don't even build the System.Runtime.Loader package any more, nor will it be brought in by any of the packages we build today.

I'm getting this on Azure DevOps with NUnit tests against net472.

I can run fine locally - any way of forcing correct behaviour on the build agent?

I'm having the same issue as @phatcher with .Net 4.6.1 as the target while running unit tests. Is it not possible to use a .Net Standard 2.0 library in a .Net Framework project? That would seem to negate the entire purpose of having .Net Standard at all.

I met the same problem when I use .netcore 3.0 preview, is there any one met the same problem?

@phatcher / @jons-aura / @watsonsong can you all clarify what it is you're asking?

System.Runtime.Loader is not supported on desktop: full stop. You cannot use it there, we have no implementation of this API on .NETFramework. It's current failure mode (FileNotFoundException) is by design, we can talk about changing that (eg: PlatformSupportedException) but I suspect that's not really going to help enable whatever that's attempting to use this API.

If the ask is to support this API on desktop folks should start describing the scenarios they want to work and folks like @jeffschwMSFT and @jkotas can have a look provide a recommendation.

What I'm asking for is the ability to use a .Net Standard library built with .Net Core in a .Net 4.6 Framework project. When I run unit tests in Azure with this scenario the tests crash.

@jons-aura can you open a new issue describing that? It sounds different than what this issue is tracking (System.Runtime.Loader, specifically). I suspect you are hitting a case of missing the support libraries from your .NET Framework 4.6.1 project, but it'd be best to open a new issue that describes the issue and along with a repro if you can. Important things to note are the projects involved, their target frameworks, how they reference each other, and whether they are using nuget-packages.config vs nuget-packagereference. Tag me @ericstj on the new issue and I'll have a look. Thanks!

@ericstj My problem I think is that netframework/netcore binaries are getting mixed up during the compilation phase on Azure DevOps causing the "Could not load error..." since it's only supported on netcore

All of my projects are using packagereference and the source nuget packages are targeting both netstandard and netframework and I have the settings as below

<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>

I've also checked and the vstest.console is only picking up net472 test assemblies though the test adapter path is as per @jons-aura case to "D:\a\1\s"

It's difficult getting to a simple repo as it's a 60 project solution that's failing, whereas the 85 project solution with the library code compiles and tests correctly on DevOps; which is why I think it's some form of errant reference but I've been through the project files a number of times trying to find it.

worked for me after upgrading to 4.8

@phatcher Did you solve your problem?? I am experiencing exactly the same experience on Azure DevOps

It is not clear here what (if anything) should be fixed in the runtime repo as most people hitting this problem are usually due to a misconfiguration on their project causing .NET Core libraries to end up on their .NET Framework applications. For this reason I'll go ahead and close this issue for now but feel free to reopen if you think otherwise.

Was this page helpful?
0 / 5 - 0 ratings