Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System.Runtime.Loader not copied to output directory #22732

Closed
bencyoung opened this issue Jul 12, 2017 · 36 comments
Closed

System.Runtime.Loader not copied to output directory #22732

bencyoung opened this issue Jul 12, 2017 · 36 comments
Labels
area-System.Runtime question Answer questions and provide assistance, not an issue with source code or documentation. untriaged New issue has not been triaged by the area owner
Milestone

Comments

@bencyoung
Copy link

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

@bencyoung
Copy link
Author

bencyoung commented Jul 12, 2017

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.

@jnm2
Copy link
Contributor

jnm2 commented Jul 12, 2017

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

@bencyoung
Copy link
Author

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)

@bencyoung
Copy link
Author

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'.

@joperezr
Copy link
Member

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.

@bencyoung
Copy link
Author

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)

@bencyoung
Copy link
Author

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

image

@bencyoung
Copy link
Author

Here's a minimal reproduction

BugDemo.zip

@DVoavi-Arison
Copy link

DVoavi-Arison commented Oct 2, 2017

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

@aienabled
Copy link

aienabled commented Oct 25, 2017

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

@sereeth
Copy link

sereeth commented Dec 20, 2017

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

@jugg1es
Copy link

jugg1es commented Feb 12, 2018

any resolution to this?

@bobuva
Copy link

bobuva commented Jul 20, 2018

Asking if there's any resolution to this.

@nikunjratanpara
Copy link

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.

@alexdegroot
Copy link

alexdegroot commented Jul 29, 2018

@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.

@bobuva
Copy link

bobuva commented Aug 1, 2018

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.

@ugumba
Copy link

ugumba commented Aug 10, 2018

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.

@joperezr
Copy link
Member

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

@mwadams
Copy link

mwadams commented Aug 23, 2018

Here's a simple repro.
Repro.zip

@joperezr
Copy link
Member

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.

@joperezr
Copy link
Member

cc: @ericstj as FYI.

@devr24
Copy link

devr24 commented Sep 17, 2018

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)??

@joperezr
Copy link
Member

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.

@devr24
Copy link

devr24 commented Sep 18, 2018

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.

@janmuncinsky
Copy link

@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.

@ericstj
Copy link
Member

ericstj commented Dec 5, 2018

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.

@phatcher
Copy link

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?

@jons-aura
Copy link

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.

@watsonsong
Copy link

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

@ericstj
Copy link
Member

ericstj commented Mar 15, 2019

@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.

@jons-aura
Copy link

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.

@ericstj
Copy link
Member

ericstj commented Mar 15, 2019

@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!

@phatcher
Copy link

@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.

@apobekiaris
Copy link

worked for me after upgrading to 4.8

@CleverAtBen
Copy link

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

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the Future milestone Jan 31, 2020
@maryamariyan maryamariyan added the untriaged New issue has not been triaged by the area owner label Feb 23, 2020
@joperezr
Copy link
Member

joperezr commented Jul 1, 2020

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.

@joperezr joperezr closed this as completed Jul 1, 2020
@dotnet dotnet locked as resolved and limited conversation to collaborators Dec 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Runtime question Answer questions and provide assistance, not an issue with source code or documentation. untriaged New issue has not been triaged by the area owner
Projects
None yet
Development

No branches or pull requests