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

Question

I've some problem when using .net standard in .net framework 4.6.2 consoleapps.

I could reduce the problem to this: Given:

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

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

Now I create a new .net 4.6.2 console application which is just calling 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: 'The File or Assembly "System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a was not found

When I add the .net standardlib nuget package to the .net fx console it works. but then the system.runtime would be aviable via GAC and via nuget reference which seems to be quite ugly for me.

I pushed this short test solution here: https://github.com/Gentlehag/NetStandardSample

What am I missing?

Gules

Answer 1

I've added a repo that shows you how to do this. From the README.md:

Requirements

Generally speaking, using libraries targeting .NET Standard in an application targeting .NET Framework requires the application project to include a NuGet reference for .NET Standard (NETStandard.Library). This ensures that the right set of assemblies are included with the application.

In Visual Studio 2015, the default way of consuming NuGet packages from .NET Framework projects is via packages.config. I don't recommend this path as this means that all assemblies are directly injected into the application project, which will significantly bloat your project file. Instead, I recommend you use project.json. To do this, perform the following steps:

1. Uninstall all packages (if you're still using packages.config)
2. Delete the empty packages.config

3. Add 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 the NETStandard.Library package, but you need to make sure to keep the framework moniker in sync with the version of .NET Framework your app is targeting, i.e. when you're targeting .NET Framework 4.6.1, you need to make sure to use net461 instead.

This feels clumsy

Yes it is. We're planning on addressing this in two ways:

• We're replacing project.json with an MSBuild based solution in Visual Studio 2017. You'll still need to add the reference to NETStandard.Library, but you no longer have to mess with the way packages are being represented nor having to manually keep targeting information in sync.

• We're planning to update .NET Framework so that future version of it come with built-in support for .NET Standard, in which case the reference will no longer be needed.

Persson

Many Thanks for t his clarification. how should I add the package in VS2017 RC ? There I don't have the package.json anymore and i'm not sure wether there is an equivilant replacement for the dependencies section ? – Gules

In VS2017 we've replaced project.json with a new MSBuild item group <PackageReference>. That's even easier than project.json. For .NET Framework apps, we'll allow you to use package.config or the MSBuild-way and AFAIK the plan is to prompt you on first use. However, I don't think that's available in the current RC of VS2017 yet. I'll ask. – Persson

Answer 2

I found that adding the NETStandard.Library did not work for me, but ensuring that binding redirects were generated on build did the trick. For that you should ensure that you have

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

somewhere in your project file. This should work for console or web apps. If you're having problems running unit tests, you can use this:

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

The GenerateBindingRedirectsOutputType is necessary as the unit tests are contained in a class library which doesn't have executable output by default, so this forces any redirect configuration to be written into the build artifacts, ready to be used when the tests are executing.

You can find more details of the issues involved here: https://github.com/dotnet/announcements/issues/31

Hugohugon