'Could not load file or assembly 'netstandard, Version=220.127.116.11, ...'. Reference assemblies should not be loaded for execution
Goal: From a .NET 4.7 console app, using reflection with Assembly.GetType(), I am trying extract the Type of a netstandard 2.0 class from Assembly X. Then I want to create an instance of this Type with Activator.CreateInstance().
What I am trying to do: However, this assembly X has a dependency to netstandard 2.0. To be able to get the Type, netstandard dependency has to be loaded into the AppDomain. That's why when the AppDomain is requesting the netstandard assembly through the AssemblyResolve event, I simply load the dll like this :
var netStandardDllPath = @"C:\Users\xxx\.nuget\packages\NETStandard.Library.2.0.0-preview1-25301-01\build\netstandard2.0\ref\netstandard.dll"; return Assembly.LoadFrom(netStandardDllPath);
System.BadImageFormatException: 'Could not load file or assembly 'file:///C:\Users\vincent.lerouvillois.nuget\packages\NETStandard.Library.2.0.0-preview1-25301-01\build\netstandard2.0\ref\netstandard.dll' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058)'
Inner Exception: BadImageFormatException: Cannot load a reference assembly for execution.
What I know: I know that they want us to load the DLL with Assembly.ReflectionOnlyLoadFrom. But doing that will prevent me from instanciate the type with Activator.CreateInstance(). See Microsoft official post
Also, I tried referencing the Nuget packages NETStandard.Library 2.0.0-preview1-25301-01 and NETStandard.Library.NETFramework 2.0.0-preview1-25305-02 in my console app so it would have the netstandard 2.0 libraries referenced, but it didn't change anything.
Question: Does anyone would know if there is a proper way to load that dll without error, or maybe if this is a bug, or else? Or why this kind of dll is not able to load for execution?
The netstandard.dll you are trying to load is a reference assembly that which cannot be loaded for runtime on .NET Framework as pointed out by others. However if you need to resolve that dependency you will need to runtime version that maps to the framework you are trying to run on.
For .NET Standard support we are including them as part of the msbuild extensions that ship with VS so you will want to get the version of netstandard.dll from there. Depending on which version of VS2017 you have installed it should be somewhere like
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\netstandard.dll or from the .NET Core 2.0 SDK you can find it
Try using one of those versions in your scenario.
Copy Enbale to true in netstandard.dll properties.
- Open Solution Explorer and right click on netstandard.dll.
Copy Enbaleto true.
You can't load a reference assembly.
.NET Standard is a collection of APIs that must be provided by .NET Standard compatible implementations.
A reference assembly only contains contracts. This means that it contains no implementation. The assembly you are trying to load contains the .NET Standard 2.0 contracts.
A contract looks like this: https://github.com/dotnet/standard/blob/master/netstandard/ref/mscorlib.cs
EDIT: .NET Framework 4.7 implements .NET Standard 2.0, so you shouldn't need to load any assembly to use
Activator.CreateInstance() to instantiate a .NET Standard type.
NETStandard 2.0.0-preview1 in not compatibility with net461 and net47.
but for realese .NET Core SDK 2.0 assemblies (as well as 2.0.0-preview2)
var netStandardDllPath = @"c:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.netcore.app\2.0.0\ref\netcoreapp2.0\netstandard.dll"; Console.WriteLine(Assembly.LoadFrom(netStandardDllPath).FullName);
all is ok.
But if you steel need to load preview1 libraries, maybe you should to use netstandard2.0 instead net471.
Wow. I just spent several hours tracking the cause of this "could not load ... netstandard" error down.
For me, the problem was that my .NET Framework project (which references both .NET Framework and .NET Standard libraries) was built with .NET Framework 4.7.2 and the system where I was deploying and running it did not have 4.7.2 installed.
Deploying a very small Console project with the same basic structure and references and executing that in a Command window finally revealed the correct error, in a pop-up, that .NET Framework 4.7.2 was missing.
If you're struggling with this particular error, make sure you have the necessary .NET Framework installed.
- Never, never load a reference assembly, they are only suitable to build your program. This went wrong because you wrote the AssemblyResolve event handler, should work just fine without it. The key is to let the CLR figure out the real runtime assembly that contains the type, good odds that this workaround works on .NETCore as well.
- Thank you, I found one that worked for me here: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\netstandard.dll. I needed it for the xUnit console test runner. I am running .Net Framework 4.5.2 on my target machines, and this 4.6.1 netstandard.dll worked for me with xUnit.
- i fixed the issue by adding following at the end of .csproj : <Reference Include="netstandard, Version=18.104.22.168, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51"> <HintPath>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\netstandard.dll</HintPath> <Private>True</Private> </Reference>
- This helped me resolve a problem I was facing when deploying a wpf app. Thanks so much!
- You want to be careful to not use that netstandard.dll as that one is for .NET Core applications and will likely cause other issues when trying to run it on .NET Framework. See my answer for where to find the .NET Framework version.
- One clue that this is the case (as it was for me) is if you have one environment working property and another one isn't even if the application files are the same. Thanks for pointing this out MikeZ.