My understanding is that, starting with ASP.NET Core 3.0, .NET Framework is an unsupported target framework, and thus you can only run on the .NET Core runtime.
If this is the case, what NuGet packages can be imported into an ASP.NET Core 3 app?
I assume that you could reference any package that targets netstandard, but what about packages that only target the full framework (i.e., a legacy package that only targets net45)?
What happens if the package you import references an assembly that's not part of .NET Core—i.e., System.Drawing?
TL;DR: You can still reference (packages which depend upon) .NET Framework assemblies from .NET Core 3 and even .NET 5, but you will receive a runtime error if you call into any code which relies upon APIs or libraries not (yet) supported by .NET Core. You can discover these using Microsoft's .NET Portability Analyzer
Background
First off, you're correct that ASP.NET Core 3.x applications can no longer target the .NET Framework, as announced by Microsoft in 2018. That capability previously allowed ASP.NET Core applications to call into .NET Framework libraries, and thus offered an intermediate solution for web applications migrating to .NET Core.
Note: Since the .NET Framework only runs on Windows machines, writing ASP.NET Core web applications which targeted the .NET Framework implicitly restricted those applications to running on Windows.
Behavior
Even when targeting .NET Core or now .NET 5, however, you're still able to reference .NET Framework packages and assemblies, assuming you're on a Windows machine and have the corresponding .NET Framework installed. The inner workings of this are a bit involved, but the short of it is that .NET Core and .NET 5 will evaluate .NET Framework assembles as though they are .NET Standard assemblies. If the API call is also implemented in the .NET Core runtime, it will work fine—but if the API call is exclusively part of .NET Framework, you'll receive an exception.
Surprise! It's really important to emphasize that this is a runtime exception. You will still be able to reference the .NET Framework assembly, write calls to problematic members, and compile your code without any warnings. But as soon as you call into code dependent on a .NET Framework-specific assembly, you'll receive the runtime exception.
Example
With .NET 3.0, a significant portions of .NET Framework libraries have been ported over to .NET Core. In fact, this includes most of the System.Drawing libraries you referenced as an example—though there are good reasons you may not want to use them. If you dig a bit deeper, however, there are plenty of libraries which remain unsupported. One obvious example is the WebConfigurationManager, which could be used to access configuration settings from web.config files.
.NET Framework Code
So, as an example, let's say you have the following function in a .NET Framework class library, which returns an array of keys from your web.config's <AppSetting>s element:
public static class Configuration
{
public static string[] GetAppSettings() => System.Web.Configuration.WebConfigurationManager.AppSettings.AllKeys;
}
ASP.NET Core Code
And then, in an ASP.NET Core controller, you expose an endpoint to retrieve this data:
public class MyController: Controller
{
public IActionResult ApplicationKeys() => Content(String.Join(", ", Configuration.GetAppSettings()));
}
Exception
In an ASP.NET Core 2.x application targeting the .NET Framework, this will work just fine. In an ASP.NET Core 3.x or ASP.NET Core 5 application, however, you'll receive the following runtime error when you call the /My/ApplicationKeys/ route:
System.TypeLoadException: 'Could not load type 'System.Web.Configuration.WebConfigurationManager' from assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.'
Avoiding Surprises
If you're anything like me, this will make you incredibly nervous. You'd much rather receive design-time errors—or, at least, compile-time warnings—as soon as you attempt to call into a library relying upon unsupported code. Fortunately, Microsoft offers a .NET Portability Analyzer, which is also available as a Visual Studio Extension, for exactly this purpose.
As of .NET 5, there's also a compatibility analyzer built into the SDK which will identify calls that are not supported by the .NET 5 runtime on particular platforms. This requires that target libraries explicitly annotate their types with the [SupportedOSPlatform()] attribute, so you won't get any warnings for legacy .NET Framework types. But this will help identify similar types of compatibility issues for libraries targeting a variety of platforms.
Example
If you run the Portability Analyzer on the above sample code, for example, it will output an Excel spreadsheet identifying that T:System.Web.Configuration.WebConfigurationManager is Not Supported in e.g. .NET Core,Version=v3.1 or .NET Standard + Platform Extensions,Version=v2.0.
Note: Microsoft used to offer an API Analyzer as a NuGet package, which promised to provide design-time analysis in Visual Studio. Unfortunately, the code hasn't been updated in two years, and the latest release is 0.2.12-alpha. In my evaluation, it was not effective at identifying issues.
Sample Project
I've put together a sample project on GitHub which demonstrates the above behavior. It includes the following projects:
ASP.NET Core 2.0 Website targeting .NET Framework 4.8
ASP.NET Core 3.1 Website targeting .NET Core 3.1
.NET Framework class library with calls to the legacy WebConfigurationManager
Both ASP.NET Core websites include two endpoints which call into the same .NET Framework 4.8 class library. The first is a "Hello world" example which will execute fine on both projects, since it relies exclusively on common APIs:
http://localhost:5000/Basic/Index
The second will fail on the ASP.NET Core 3.1 project, since it calls into the legacy WebConfigurationManager API:
http://localhost:5000/Basic/Configuration
Disclaimer: This is a quick and dirty repository that I put together to verify my understanding prior to posting this. If there's interest, I'll tidy it up and document it. For now, however, it may prove useful for those of you who need to see this in action.
Acknowledgments
#Chris Pratt offered an excellent answer covering similar material last year. It's worth reading.
I'm in the process of converting an Asp.Net Core 2.2 Website that targeted the Full Framework to an Asp.Net Core 3.1 App that targets .Net Core 3.1. I'm a bit unclear about dependencies related to System.Drawing and how to fulfill them.
My project uses System.Drawing and when compiling under Asp.Net Core 3.1 I get this error that suggests that I add a reference to System.Drawing.Common.dll :
Error CS1069: The type name 'Image' could not be found in the namespace 'System.Drawing'. This type has been forwarded to assembly 'System.Drawing.Common, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' Consider adding a reference to that assembly. 1-wwwGiftOasis3 C:\Users\Ron\source\repos\wwwGiftOasis3\wwwGiftOasis3\site\seller\profile\about\s-photos.cs
In Visual Studio I don't see a way to add a reference directly to the bare System.Drawing.Common.dll so I assume that I should add the reference via NuGet.
In NuGet I see a System.Drawing.Common package which looks like what I want but it's unclear to me whether my project fulfills the dependencies:
My Project shows these dependencies:
So I have a couple questions related to all this:
1) Does the fact my the project depends on Framework Microsoft.NETCore.App fulfill the NuGet package's Microsoft.NETCore.Platforms dependency?
2) Does the fact that I intend to only run this Asp.Net Core 3.1 website on windows fulfill the NuGet package's Microsoft.Win32.SystemEvents dependency?
System.Drawing utilizes Windows-specific APIs, and as such, is incompatible with .NET Core, which is cross-platform. Microsoft created System.Drawing.Common as an in-place replacement for System.Drawing for .NET Core. It is an exact API replacement, but performs the image operations in a cross-platform, rather than Windows-specific, way.
Long and short, yes, you just drop the NuGet into your project and go to town. There's nothing else you need to worry about.
I'm building a Web API in .NET Core 2. I'm using some custom nuget packages to leverage their built in functionality. These custom packages were built against an older .NET version (4.6.1). The problem is some of these packages have references to the old System.Web dll. I'm getting this warning on some of the custom packages in the solution
package was restored using '.net framework version=v4.6.1 instead of using the proj target framework.
The app is also throwing this exception below when I call code in one of the custom packages
System.IO.FileNotFoundException: Could not load file or assembly System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral,The system cannot find the file specified
Is there any way around this other than re-writing the code in my web Api?
No. System.Web is completely incompatible with Core. While Microsoft opened up NuGet packages that target .NET Framework to be utilized in with .NET Core, it did so based only on .NET Standard 2.0 compatibility, and makes no assurances that the packages will function in part or whole. You'll actually get a warning during compile telling you as much. Also, while you can actually have something like an ASP.NET Core app actually target .NET Framework, again, compatibility of third-party components is not guaranteed, simply because they target the same framework.
Long and short, if there's any dependency on System.Web at all, you can't use it.
Getting following error when i try to add reference of .net core library reference in my web app.
Microsoft Visual Studio
The following projects are not supported as references :
DiscoverLib has target frameworks that are incompatible with targets in current project DiscoverWeb.
DiscoverWeb: .NETFramework,Version=v4.5.2
DiscoverLib: .NETStandard,Version=v1.6
Yes, that's expected/normal. .NETStandard 1.6 requires .NET Framework 4.6.3 (aka vNext) which is an unreleased version of the .NET Framework.
See this matrix for information. If you want to target .NET Framework 4.5.1 your class library must be ".NET Standard 1.2" or lower. This reduce the number of API you can use, so you always need to balance between minimum version supported and newest API.
I have a project written in VS2012/.Net 4.5 that is essentially a bog-standard, database-first Entity Framework 5 entity model and context, and associated business domain classes. That all works fine when I'm referencing the built assembly from a VS2012/.Net 4.5 application (I've used it successfully with an MVC website and with integration test projects). However when I try to use the exact same assembly from a VS2010/.Net 4 application on the same machine, Visual Studio will add a reference to the assembly with no problem, the classes will also show up under Intellisense (I can add a using statement, for example), but as soon as I try to build the project I get the following error:
Warning 3 The primary reference "MyDotNet45Assembly" could not be resolved because it was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".
My understanding (e.g. from Scott Hanselman here) was that .Net 4.5 was an in-place upgrade to .Net 4.0, so I can't understand why I can't call an assembly created for the newer version. What am I missing or misunderstanding? I can't believe I'm the only person who has hit this issue, but I'm genuinely struggling to find anything on the web that explains what's going on.
I've looked at a number other questions on StackOverflow, none of which seem to quite cover what I'm after, e.g:
Using EF4.0 in a .Net 3.5 app
Using a .Net 4.0 assembly in a .Net 4.5 project