I've found loads of pages referencing this topic but none are clear or conclusive hence this question.
If I install a c# application built with a target Framework of .Net Core 3.1 onto a server which contains just .NET 6, will it still run without any changes?
If I upgrade the version of .NET on a Windows server from .Net Core 3.1 to .Net 6, will the applications already on that server, built with a target Framework of .Net Core 3.1, still run OK?
Thanks
Not necessarily - there are many breaking changes on every major release.
Those for .NET 5->6 are published here here. For .NET Core 3.1 -> .NET 5 see here.
Note also the distinction between binary incompatible and source incompatible
Binary incompatible - Existing binaries may encounter a breaking change in behavior, such as failure to load or execute, or different run-time behavior.
Source incompatible - Source code may encounter a breaking change in behavior when targeting the new runtime or using the new SDK or
component. Behavior changes can include compile errors or different
run-time behavior.
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 have a .Net Core 3.1 web application. Since I have to communicate to a legacy service using .Net Remoting, I decided to change the TargetFramework to 4.61. This has caused error with (IApplicationBuilder)app.UseHSTS(). So, I updated my referenced version of Microsoft.AspNetCore.SpaServices.Extension to 2.2.0. However, UseHSTS is not available with it. Is there an alternative solution?
I've got an old Windows 2003 server running IIS 6, and I chose .net 4.5 for my latest web app. Problem is I can't get it to run on the server...
.NET 4.0 framework is installed. I've run aspnet_regiis and deployed the website. I gave it it's own application pool. But I'm getting the following error:
The 'targetFramework' attribute in the <compilation> element of the Web.config
file is used only to target version 4.0 and later of the .NET Framework (for
example, '<compilation targetFramework="4.0">'). The 'targetFramework' attribute
currently references a version that is later than the installed version of the
.NET Framework. Specify a valid target version of the .NET Framework, or install
the required version of the .NET Framework.
I saw the requirements for .NET 4.5 as requiring Windows Server 2008 or later, but I'm seeing lots of posts with people just needing to configure the routing for MVC4 so it seems like this should be possible.
So any ideas what I need to do in order for this to work?
EDIT: The strange thing is we are using an ASP.NET Web API site that works just fine... but that should require .net 4.5...
.Net 4.5 cannot be installed on Windows Server 2003.
Instead, you should use MVC 4.0 on .Net 4.0, which will work fine.
I just installed the ASP.NET MVC 4.0 RC build on top of a Visual Studio 2010 SP1. My project that used to compile and work with the beta version of ASP.NET MVC 4.0, raises an error when I access the site saying that the Newtonsoft.Json assembly version 4.5 can not be found.
As I did not use this third party library in my current project, I configured Fusion Log to try to isolate the assembly that was relying on Newtonsoft.Json assembly.
And the guilty assembly is System.Net.Http.Formatting.dll which references Newtonsoft.Json version 4.5.
The beta build referenced System.Json.dll and not the Newtonsoft assembly.
I can hardly believe that Microsoft is starting to rely on external assemblies even if they publish more and more code in open source.
Does anyone have an explanation of what happened?
They are actually relying in third-party software (just like they ship MVC with JQuery and knockout.js). Scott Guthrie announced that MVC 4 will be shipped with JSON.NET (Newtonsoft). See below:
Json.NET: We plan to use the community developed Json.NET
serialization stack in our default JSON formatter in ASP.NET Web API.
Json.NET provides the flexibility and performance required for a
modern web framework.
http://aspnet.codeplex.com/wikipage?title=ASP.NET%20MVC%204%20RoadMap
You can keep the System.Json.dll btw, I've got them both. If you have any problems with JSON.NET, just reinstall it :)