Add documentation explicity stating that a console app that refrences a net standard library needs to pull NETStandard.Library

[dhoehna]

Hello,

I am new to using Visual Studio 2017. I have one console application and three class libraries. I am using Net standard 1.4 on the class libraries and net framework 4.6.1.

I would appreciate it if there was an easy way to see that, in order to get my project to work, I had to use nuget to install NETStandard.Library in the documentation. Or at least make the solution easy to find on google.

[jarenduan]

When you build your class libraries, you should restore all the dependencies first, and VS would automatically do that for you by default. So in general, you don't have to use nuget to manually install netstandard.library .

[dhoehna]

How do I restore dependencies?

[dasMulli]

You shouldn't need to manually install NETStandard.Library if you reference the library project or use a NuGet package built from a .net standard library.

(It is currently only needed to install NETStandard.Library.NETFramework if you use netstandard2.0 projects in the current VS 2017 Update 3 preview but this will probably be automatic as well)

How do I restore dependencies?

Visual Studio does this automatically be default. On command line, you'd do dotnet restore or - if needed - msbuild /t:Restore on the Developer Command Prompt

[weshaggard]

@dhoehna thanks for posting the request I do think we need some documentation around this space. Our hope is that we will get most of the tools to implicitly understand and reference the packages as needed but currently you need to reference NETStandard.Library (pre NS2.0) or NETStandard.Library.NETFramework (post 2.0) from your .NET Framework project in order for everything to work as expected.

@terrajobst you are planning to write some documentation on this subject can you add some docs in the standard repo on this topic?

[dhoehna]

Hey all. Let me put in more detail my problem since there have been questions.

I have one solution and 4 projects in that solution.

1. Mazes - Console Application - .NET Framework 4.6.1
2. MazeGenerator - Class Library - .NET Standard1.6
3. MazeAlgorithms - Class Library - .NET Standard 1.6
4. Grid - Class Library - .NET Standard 1.6

This configuration won't build. I get the following error Project 'C:\git\MazeAlgorithms\CSharp\Mazes\MazeGenerator\MazeGenerator.csproj' targets '.NETStandard,Version=v1.6'. It cannot be referenced by a project that targets '.NETFramework,Version=v4.6.1'.

I get that error for each class library I have.

Which is odd since, accoring to your versions I can use .NET Framework 4.6.1 and .NET Standard 1.6 together.

In order to remedy this error, I changed all class libraries to target .NET Standard 1.4 instead.

Changing the .NET Standard removed the errors. My code runs fine after that. However, I added a Console.WriteLine(); in the MazeAlgorithm project and got the following error at run time System.IO.FileNotFoundException: 'Could not load file or assembly 'System.Console, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.'

I fixed this issue by installing NETStandard.Library.

Which, is the reason for this issue.

[weshaggard]

Which is odd since, accoring to your versions I can use .NET Framework 4.6.1 and .NET Standard 1.6 together.

It will be mapped to that once we release the updated nuget tools for it. Currently if you are using the released VS2017 tools it maps to netstandard1.4.

I fixed this issue by installing NETStandard.Library.

Correct right now the tooling doesn't automatically include the necessary NETStandard.Library or NETStandard.Library.NETFramework reference so it has to be manually added to your .NET Framework project.

[dhoehna]

I see. I'm glad to know what I was doing to correct the problem is correct. It would be nice to have some official documentation that explains the behavior and how to fix it. Or, a step-by-step guide on how to correctly intermingle the net standard and net framework.

@weshaggard Do you know when the update will be released?

[weshaggard]

See https://github.com/dotnet/core/blob/master/roadmap.md which we are targeting Q3 2017.

[clairernovotny]

@weshaggard Is it in the plan that existing project types will automatically infer the NETStandard.Library.NETFramework package by the time Update 3 is done?

[Petermarcu]

That is the goal.

[clairernovotny]

@Petermarcu so if I understand correctly, since Update 3 will add NETStandard.Library or NETStandard.Library.NETFramework to existing project types automatically if any of the dependencies are .NET Standard, then the dialog box showing >50 dependencies will go away even if the library they're referencing is NETStandard 1.3 and itself has a dependency on the 1.6.1 meta-package? That's great news!

What about the Xamarin project types? It would be great if one of the meta-packages could be auto-added there too for the same reasons.

[Petermarcu]

@morrisjoe @rrelyea are working on this and should be able to provide more details.

[Petermarcu]

cc @terrajobst as well

[tannergooding]

@Petermarcu, could you provide some details as to why a new package is required here (NETStandard.Library.NETFramework) rather than just providing the appropriate libraries in the existing NETStandard.Library package (so that the default transitive flow just works when referencing a netcore/netstandard project from a desktop project)?

[Petermarcu]

I believe the thinking here is changing again. I think this is getting moved out of a package and into an installer of some kind. @dsplaisted to fill in details.

[tannergooding]

Thanks @Petermarcu. @terrajobst, it would be great if we could get a blog post on this explaining the change and the workaround (it's obvious that customers trying out 15.3 Preview 1 are hitting this and finding out how to fix it can take some digging).

[d-saravanan]

I am using VS 2017 Preview 3, but getting the same error for aspnet/security repository. Can anyone help, I tried using VSCode, but that again is a failure. I am not sure why the process of building and running code can be so messy!!!!

[dasjestyr]

NETStandard.Library.NETFramework package says that it is deprecated and that you only need the Core 2.0 SDK to be installed in order to consume .NET Standard libraries which I'm finding to be untrue. I am using 15.3.3 and still can't consume netstandard2.0 libraries from a net461 application

[weshaggard]

The package is deprecated because we shipped this support in the tools. If it isn't working for you I suggest filing an issue at http://github.com/dotnet/sdk with the repro steps.

[dasjestyr]

dotnet/sdk#901

[d-saravanan]

I was having similar issues and updated to visual studio 2017 15.4 and now I'm able to use .net core 2 easily. Please update the VS 2017, it may help you

[jpenniman]

We're having a similar issue when using a NetStandard2.0 class library in a net461 project, whether its a project reference or a nuget package.

We're building a logging library (NetStandard2.0) for use in both WebApi 5.2 and ASP.net Core 2. The library uses Microsoft.Extensions.Logging.Abstractions 2.0. We also have a library (net461) that references Microsoft.Extensions.Logging.Abstractions and Microsoft.AspNet.WebApi.Core and implements an ExceptionLogger. The constructor of our ExceptionLogger takes in ILogger from Microsoft.Extensions.Logging.Abstractions.

public class GlobalExceptionLogger : ExceptionLogger
{
    ILogger logger;

    public GlobalExceptionLogger(ILogger logger)
    {
        this.logger = logger;
    }

    public override Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken)
    {
        var request = context.Request;
        logger.LogError(context.Exception, "Error Processing request: {requestUri}", request.RequestUri.ToString());
        return Task.CompletedTask;
    }
}

The code builds just fine, but at runtime, we receive:

[MissingMethodException: Method not found: 'System.Net.Http.HttpRequestMessage System.Web.Http.ExceptionHandling.ExceptionLoggerContext.get_Request()'.]
   MilestoneTG.Infrastructure.Monitoring.WebApi.GlobalExceptionLogger.LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken) in C:\dev\MilestoneTG.Infrastructure.Monitoring\MilestoneTG.Infrastructure.Monitoring.WebApi\GlobalExceptionLogger.cs:24
   System.Web.Http.ExceptionHandling.ExceptionLogger.System.Web.Http.ExceptionHandling.IExceptionLogger.LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken) +56

We've tried adding a reference to NETStandard.Library and enabling PackageReferences, but it doesn't help. If we remove the line that uses the missing getter and related code, it works.

Targeting net471 for our WebApi project makes it even worse and doesn't compile with the same error others are seeing in this thread: error CS0012: The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. Referencing NETStandard.Library doesn't help there either.

We're using the latest VS 2017 (15.4.3) and dotnet tooling/SDK (2.0.2).

[weshaggard]

@joperezr would you mind looking into this issue?

[stijnherreman]

@jpenniman I'm seeing the same issue after upgrading from net461 to net471. And I'm only doing the upgrade to fix the issues from #481, so it's annoying to be stuck again.

The strangest thing is that this problem only happens in the unit test project. The main project already included NETStandard.Library and everything worked (apart from the #481 issues), but after upgrading the projects to net471, the unit test project can't resolve ValueType and IEnumerable<>.

[joperezr]

sure I'll take a look to the issue.

@stijnherreman I understand your frustration and I apologize for the issues you are hitting. do keep in mind that full support of netstandard when targeting 471 will come in the next update: 15.5, but I'll take a look since there might be some tweeks you can set in your project file that will make all of this work. For instance, one workaround that jumps to mind that might fix your problem, is can you try setting these two properties on your net471 project:

 <PropertyGroup>
   <DependsOnNETStandard>true</DependsOnNETStandard>
   <NETStandardInbox>false</NETStandardInbox>
 </PropertyGroup>

This might make it work for now but as I said, we are currently trying to fix these kind of issues for our next release (15.5)

[joperezr]

@jpenniman I would advise to not target 471 until 15.5 is released since as I said on my previous comment, that is really when we will support using netstandard assets on 471. Now as for your 461 problem, I believe your issue is different and have nothing to do with NETStandard.Library or NETStandard.Library.NETFramework packages. The reason is that those two will only pull the required shims so that your project will resolve to the same type universe, but the problem in your case seems to be that the type did resolve, but the method didn't. Are you referencing package Microsoft.AspNet.WebApi.Core? That seems to be the place where the implementation of that member should come from, and if you are implementing it, can you check if System.Web.Http.dll is deployed in your bin folder with your app?

[stijnherreman]

@joperezr thanks, I'll take a look at that on Monday. Meanwhile I had already managed to get it working with <_HasReferenceToSystemRuntime>true</_HasReferenceToSystemRuntime> (found that in another similar issue), is one of the methods preferred or do they both have the same effect?

[joperezr]

They should have the same effect which is basically force the compatibility shims to be deployed with your app, so if that works for you then that is fine. We will continue making improvements on 15.5 so that manual work and workarounds won't be required anymore.

[jpenniman]

@joperezr, thanks. System.Web.Http was deployed to the bin folder, oddly, it ended up being an issue with System.Net.Http. I explicitly added the latest nuget package to the web api project and manually add the binding redirect to the version in the nuget package. After I did that, it worked. My sense is it was pulling from the gac, which is a newer version (because 4.7.1 is installed) than what is in nuget ( 4.2.0.0 vs 4.1.1.2) and something in the dependency tree wasn't happy with it despite no assembly resolution errors.

It feels like going back to shipping everything with 4.7 and moving away from providing the framework purely as nuget packages was a step backwards. In our experience pulling everything in as nuget packages solved a lot of dependency and deployment issues.

[joperezr]

System.Net.Http is a very special case that has a bug in 4.7.1. Basically it's version is incorrect inbox, version is v4.0.0.0.0 so if you have any assembly that compiled against packages (like a netstandard1.6 assembly for example) then it would be referencing a higher version of the library (either 4.1.1.2 or 4.2.0.0). So when you try to run this on 4.7.1 it will fail since it won't be able to find that version of the assembly. Adding the file to the bin folder and the binding redirects is a valid workaround. We have fixed this for our next release of desktop, so the version inbox will be correct and no binding redirects will be required.

[hamidzokaee]

hi
This error occurred when installing EntityFrameworkCore 2.1.4 How can I fix this:
To reference a library that targets.NET Standard 1.5 or higher, you need to install the .NET Standard Build Support extension for the .NET Framework from https://aka.ms/netstandard-build-support-netfx
info :
Microsoft Visual Studio Enterprise 2015
Version 14.0.25420.01 Update 3
Microsoft .NET Framework
Version 4.7.03062
Installed Version: Enterprise
NuGet Package Manager 3.6.0

[terrajobst]

I believe this issue is sufficiently described in our documentation now.