Executing a .NET Framework 4.6.1 console app that references a .NET Standard 2.0 assembly fails with
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
at TestApp.Program.Main(String[] args)
Create a .NET Framework 4.6.1 app that references a .NET Standard 2.0 library.
Example: TestApp --> TestLib
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
</Project>
```c#
using System.Runtime.InteropServices;
namespace TestLib
{
public class Class1
{
public static string FrameworkDescription => RuntimeInformation.FrameworkDescription;
}
}
#### TestApp
```xml
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<ProjectReference Include="..\TestLib\TestLib.csproj" />
</ItemGroup>
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net461</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="NETStandard.Library" Version="$(BundledNETStandardPackageVersion)" />
</ItemGroup>
</Project>
```c#
using System;
using TestLib;
namespace TestApp
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine(Class1.FrameworkDescription);
}
}
}
```
dotnet/cli: 2.0.0-preview2-005905
NETStandard.Library package version: 2.0.0-preview2-25226-01
Looks like https://github.com/dotnet/sdk/issues/992#issuecomment-299380272
You need to add a reference to NETStandard.Library.NETFramework package to get this dependency now.
Thanks, that fixes it. I never would have figured that out from error messages or tooling alone. I'm assuming this is just a pre-release rough edge. Are there plans to make the reference automatic or to make this more obvious to end users?
Correct that is the sdk bug that was linked above.
Ok, thanks.
Hi Guys,
I am having exact same issue, but in my case I am creating a extension package, I tried all the workaround suggested, but had no luck, I added NETStandard.Library.NETFramework as well on the extension package but still having same exact problem, any thoughts would be appreciated!
thanks
System.IO.FileNotFoundException: 'Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.'
I think the NETStandard.Library has to be added to the .NET Framework app. In my case, the ..NET Framework app is a shipping version of PowerShell 5.1. I'm trying to build netstandard2.0 based PowerShell module i.e. extension. The module loads but fails when I execute my custom command with the same error.
Not sure whether to create a new issue, I'll post it here because it seems to fit.
The code below is run from a .net 4.6.2 console and ClassLibrary2.dll is a .net standard 2.0 library.
GetExportedTypes() method would throw
System.IO.FileNotFoundException: 'Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.'
unless I add the deprecated NETStandard.Library.NETFramework to the console.
const string file = @"[PATH]\ClassLibrary2.dll";
var assembly = Assembly.LoadFile(file);
var types = assembly.GetExportedTypes();
Where can I find NETStandard.Library.NETFramework? Nuget only finds NETStandard.Library.
@kwaazaar
It's NETStandard.Library.NETFramework and make sure you tick "Include prerelease" checkbox.
It should no longer be necessary to use the NETStandard.Library.NETFramework, it was a temporary method. The tooling is now included in VS (with some issues - see
https://github.com/dotnet/announcements/issues/31)
If you load an app via reflection and not during the build process, you should be able to force the build process to run the necessary logic by putting this into a PropertyGroup in your consuming application:
<DependsOnNETStandard>true</DependsOnNETStandard>
If you run on 4.7.1, it should work out of the box (haven't tried though)
Added NETStandard.Library.NETFramework to a 4.6.2 Console application, which references a .NET Standard 2.0 library. Also added
<DependsOnNETStandard>true</DependsOnNETStandard>
to a PropertyGroup in the console application.
Recieving the following error:
_System.IO.FileNotFoundException: 'Could not load file or assembly 'Titanium.Web.Proxy.Standard, Version=3.0.130.0, Culture=neutral, PublicKeyToken=8e41e1f1c790d7cf' or one of its dependencies. The system cannot find the file specified.'_
@dasMulli Indeed it works that way. Didn't try 4.7.1.
In my case, one of my DLL's consistently gives this error and refuses to load (while all others load fine).
The root of my main program is .NET Core APP, while all the DLL's are .NET Standard 2.0.
Turns out that I need to reference NetStandard.Library in the main .NET Core APP to get the error to go away. No idea why all other DLL's don't require it though...
Anyway:
~
~
does the magic.
If I'm targeting net462 i'm getting netstandard in my output (Service Fabric application) but if net472 then I'm not (because it's GAC'd as part of the SDK installation) so it's not getting packaged thus not deployed to the cluster, and the app doesn't work. Thoughts?
@weshaggard @karelz
What is the current solution for this now that the https://www.nuget.org/packages/NETStandard.Library.NETFramework/ is deprecated?
Using VS2015, .Net461,
I need to reference netstandard2 in my project to use some abstractions from another package. When I try to deploy my cloud service to azure I get a "Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies"
thanks in advance
I don't believe it is supported in VS2015. If you have the newer VS2017 tooling it will copy this binary into your output automatically as part of the build.
It will if targets net462, it won't if targets net472
How is it possible that this bug still exists? And no official solution?!
@eluchsinger this bug was closed more than a year ago: https://github.com/dotnet/standard/issues/328#event-1071274133 (so was the other one linked above: https://github.com/dotnet/sdk/issues/992#event-1071389947)
Either you're using old bits, or there is a new/different bug with similar symptoms, or the original bug was not properly addressed. Either way, I'd recommend to try latest bits which are supposed to be fixed (from the linked SDK bug). If it still fails, please provide detailed information about what fails for you under which conditions, etc. -- ideally minimal repro -- in a new bug. Thanks!
Was it fixed? If yes then wheere and how? And what should be done to dtart using it? There are so many discussions that went nowhere so it's hard to tell what was the final outcome.
@karelz it's really hard to provide a repro when the source for the error is hidden somewhere in the configs of our solution and the error message is not helpful.
I see that in the second link you posted (dotnet/sdk#992 (comment)) there are unanswered questions in the end.
I am using Visual Studio 15.8.1. I am targeting net472 and I get that error. I have also added NETStandardLibrary (latest) as a Nuget, but it didn't help. I will spend more time debugging tomorrow.
cc @joperezr @safern @weshaggard if they have any pro tips / suggestions how to debug it (MSBuild logs?).
It will if targets net462, it won't if targets net472
That is by design. Net472 doesn't need the support package, because the required files we need in order to run are already installed in the GAC for .NET Framework 4.7.2.
For people still hitting this, and specially if they are hitting it at build-time, then please do upload a msbuild binlog file here so that we can take a look and figure out what is going on. In order to produce a binlog simply run msbuild yourProject /t:rebuild /bl from a developer command prompt.
So I switched my project to net472, built and netstandard.dll is not in the output. So the app won't work on Service Fabric Cluster which doesn't have net472 installed yet. What's not the case for net462 which brings netstandard.dll with it.
I've switched my .net core console project targeted at full framework from net471 to net461 and it does now include netstandard.dll in the output which wasn't the case before. It definitely seems like a bug, fortunately I should be fine with slightly lower framework version.
Right. Netstandard.dll is built into 4.7.1 so you don't need it in your app if you are guaranteed to run on 4.7.1 or higher. That's the designed behavior.
Executing a .NET Framework 4.6.1 console app that references a .NET Standard 2.0 assembly fails with
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified. at TestApp.Program.Main(String[] args)Repro
Create a .NET Framework 4.6.1 app that references a .NET Standard 2.0 library.
Example: TestApp --> TestLib
TestLib
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netstandard2.0</TargetFramework> </PropertyGroup> </Project>using System.Runtime.InteropServices; namespace TestLib { public class Class1 { public static string FrameworkDescription => RuntimeInformation.FrameworkDescription; } }TestApp
<Project Sdk="Microsoft.NET.Sdk"> <ItemGroup> <ProjectReference Include="..\TestLib\TestLib.csproj" /> </ItemGroup> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>net461</TargetFramework> </PropertyGroup> <ItemGroup> <PackageReference Include="NETStandard.Library" Version="$(BundledNETStandardPackageVersion)" /> </ItemGroup> </Project>using System; using TestLib; namespace TestApp { class Program { static void Main(string[] args) { Console.WriteLine(Class1.FrameworkDescription); } } }Details
dotnet/cli: 2.0.0-preview2-005905
NETStandard.Library package version: 2.0.0-preview2-25226-01
I ran into the same issue, found out that below entry is added to .csproj file when dependency package is added.
<Reference Include="System.Buffers, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">
<HintPath>..\packages\System.Buffers.4.5.0\lib\netstandard**2.0**\System.Buffers.dll</HintPath>
</Reference>
Edit this file manually, change it as shown below. It should resolve it.
<Reference Include="System.Buffers, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">
<HintPath>..\packages\System.Buffers.4.5.0\lib\netstandard**1.1**\System.Buffers.dll</HintPath>
</Reference>
I have the same problem and got fixed when updating the .NET Framework from 4.6.2 to 4.7.1
After installing Dot net framework 4.7.2, issue is resolved.
I have the same error with .net Core 3 with Azure function version 2 (Visual studio 2019 with .net framework 4.8).
System.Private.CoreLib: Exception while executing function:
Microsoft.Extensions.Configuration.AzureAppConfiguration: Could not load file or assembly 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
System.Private.CoreLib: Could not load the specified file.
I have opened a issue here :
https://stackoverflow.com/questions/58842042/exception-while-executing-azure-function-v2-with-aspnetcore3-the-system-cannot
After a publish i was seeing this:
Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
It was because my publish didn't copy all of the bin files. Delete the published files and manually copy, and it started working.
Most helpful comment
It should no longer be necessary to use the
NETStandard.Library.NETFramework, it was a temporary method. The tooling is now included in VS (with some issues - seehttps://github.com/dotnet/announcements/issues/31)
If you load an app via reflection and not during the build process, you should be able to force the build process to run the necessary logic by putting this into a
PropertyGroupin your consuming application:If you run on 4.7.1, it should work out of the box (haven't tried though)