6
votes

I've got a project that I want to use .net core 2.0, which I believe is netcoreapp2.0. It is also using a nuget package that is created with .net 4.6.1. I have control over this nuget package and can change something there if need be. It does have netstandards 2.0 imported as a nuget package.

If I include in my cproj file:

    <TargetFramework>netcoreapp2.0</TargetFramework>

I get this warning :

Package 'Terryberry.Roes.Common 2017.9.29-mongo' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.

along with errors about system.net.sockets being downgraded from 4.3 to 4.1. The 4.6.1 nuget package has System.Net.Sockets 4.3 so I'm not sure why it wants to downgrade.

The exact error for reference:

Detected package downgrade: System.Net.Sockets from 4.3.0 to 4.1.0. Reference the package directly from the project to select a different version. MyNetCoreProject (>= 2017.2.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> Microsoft.Extensions.FileProviders.Physical (>= 1.1.1) -> NETStandard.Library (>= 1.6.1) -> System.Net.Sockets (>= 4.3.0) MyNetCoreProject (>= 2017.2.0) -> Microsoft.VisualStudio.Web.BrowserLink (>= 1.1.2) -> System.Net.Sockets (>= 4.1.0) MyNetCoreProject

I tried targeting both:

    <TargetFrameworks>net461;netcoreapp2.0</TargetFrameworks>

This gives me warnings like :

Package 'My461NugetPackage' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.

This confuses me too because now I added net461 and it says its going to build it with .NetCoreApp

There are still errors about downgrading System.Net.Sockets

I then decided I was willing to try just net461. Just to see if it would compile. It does, but I get a runtime error.

    <TargetFramework>net461</TargetFramework>

This gave me:

Unhandled Exception: System.TypeLoadException: Method 'ConfigureAppConfiguration' in type 'Microsoft.AspNetCore.Hosting.WebHostBuilder' from assembly 'Microsoft.AspNetCore.Hosting, Version=1.1.2.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' does not have an implementation.

I've tried doing some research, but there is a lot of old/obsolete information about there as .net core is evolving. I haven't been able to figure this out. Any guidance would be appreciated.

2
Any reasons which prevents you from cross-compiling your class library to net461 and netstandard2.0?Tseng
what do you mean by that @Tseng? I can't upgrade the 4.6.1 app to .net core yet, its a big project. I would definitely consider using net461 and netstandard2.0. Do I just set those two in the TargetFrameworks tag?bgraham
You said: It is also using a nuget package that is created with .net 4.6.1, so the question is, why you can't port/cross target it with netstandard 2.0, so I am not talking about your application, but about your library/package you reference. Then you can reference it w/o any issues in both net461 and netcoreapp2.0Tseng
maybe that's something I'll end up looking into. It's got a lot of stuff in it, porting it to netstandard 2.0 might have its own set of issues. I appreciate your advice though!bgraham

2 Answers

2
votes

First off, you can't target both. They're mutually exclusive. However, that's not a problem, because you don't need to.

The warning you're getting is by design. It doesn't prevent your app from working or really indicate any problems at all. It's just that: a warning. It's letting you know that your .NET Core project is utilizing a library that targets .NET Framework 4.6.1, which could cause a problem if and only if that library utilizes some particular framework feature that just happens to not be supported by .NET Standard 2.0. It's there simply to make you aware of what's happening and can be safely ignored as long as all your application's functionality is working fine. If the warning itself bothers you, you can simply suppress it.

This warning not only appears when installing the package, but every time you build. This ensures you don’t accidentally overlook it.

The reason for the warning is that NuGet has no way of knowing whether the .NET Framework library will actually work. For example, it might depend on Windows Forms. To make sure you don’t waste your time troubleshooting something that cannot work, NuGet lets you know that you’re potentially going off the rails. Of course, warnings you have to overlook are annoying. Thus, we recommend that you test your application/library and if you find everything is working as expected, you can suppress the warning.

Source: Announcing .NET Standard 2.0

0
votes

Not exactly what you are asking for, but one alternative way to realize that is the use of shared libraries.

It is a little bit more complex, because you have a shared library project (containing only the shared code files) and multiple other projects targeting the platform (e.g. one for .net 4.6.1 and one for .net 2.0 core, and so on). One advantage of that structure is, that you can extend the projects with platform specific code.

See this repository for example.