Using .net standard 1.5 lib in .net 4.6.2 skips System.Runtime 4.1.0.0

I have some problems when using the .net standard in the .net framework 4.6.2 consoleapps.

I could reduce the problem: Given:

I am creating a .net standard 1.5 vis vs 2017 client library with this single class

public class Class1 { public List<int> Get() { return new List<int>() { 1, 2, 3, 4, 5, 65, 6 }; } } 

Now I am creating a new console application .net 4.6.2, which simply calls the method of this class:

  static void Main(string[] args) { var foo = new Class1(); Console.WriteLine("Done!"); Console.ReadLine(); } 

Now i get

System.IO.FileNotFoundException: 'File or assembly' System.Runtime, Version = 4.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a not found

When I add the .net standardlib nuget package to the .net fx console, it works. but then system.runtime will be available through the GAC and through the link to nuget, which seems pretty ugly to me.

I clicked here a short test solution: https://github.com/Gentlehag/NetStandardSample

What am I missing?

+7
c # visual-studio-2017 .net-standard
source share
2 answers

I added a repository that shows how to do this. From README.md:

Requirements

Generally speaking, using libraries designed for the .NET Standard in the .NET Framework targeting application requires that the application project include a NuGet link for the .NET Standard ( NETStandard.Library ). This ensures that a set of assemblies is included in the package.

Visual Studio 2015 uses NuGet packages with .NET by default. Framework projects: packages.config . I do not recommend this path as it means that all assemblies are directly entered into the project application, which will greatly inflate your project file. Instead, I recommend you use project.json . To do this, follow these steps:

  • Remove all packages (if you are still using packages.config )
  • Delete empty packages.config
  • Add a project.json file with this content:

    json { "dependencies": { "NETStandard.Library": "1.6.0" }, "runtimes": { "win": {} }, "frameworks": { "net462": {} } }

Please note that you can generally depend on the latest version of NETStandard.Library , but you must be sure to keep the moniker framework in sync with the version of the .NET Framework your application is configured to, i.e. when you target the .NET Framework 4.6.1, you need to make sure that you are using net461 .

It seems awkward

Yes it is. We plan to consider this in two ways:

  • We are replacing project.json with MSBuild for Visual Studio 2017. You still need to add a link to NETStandard.Library , but you no longer have to bother with how the packages are presented and to manually synchronize the targeting information.

  • We plan to update the .NET Framework so that in a future version there is built-in support for the .NET Standard, in which case the link will no longer be necessary.

+9
source share

I found that adding NETStandard.Library did not work for me, but ensuring that link redirects were generated during assembly did the trick. To do this, you must make sure that you have

 <PropertyGroup> <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> </PropertyGroup> 

somewhere in the project file. This should work for console or web applications. If you are having trouble running unit tests, you can use this:

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

GenerateBindingRedirectsOutputType necessary because unit tests are contained in a class library that does not have executable output by default, so this forces any redirection configuration to be written to assembly artifacts, ready to be used when tests are executed.

More information about the problems can be found here: https://github.com/dotnet/announcements/issues/31

0
source share

All Articles