One of my our application uses System.Web.Http to support ExceptionHandler in ASP.NET 4.x for the existing code. Currently I am migrating all the class library to .Net 6 Class library. However, System.Web.Http nuget package is not available for .NET 6.
Is there any alternative package to support ExceptionHandler in .NET 6?
Tried many NuGet package packages. Didn't work out.
The System.Web.Http namespace does not exist in the .Net Core 6.
See the documentation: Migrate from ASP.NET Web API to ASP.NET
To migrate to ASP.NET Core:
Remove using statements for the following ASP.NET 4.x components that
don't exist in ASP.NET Core:
ApiController class
System.Web.Http namespace
IHttpActionResult interface
How to process error exceptions in ASP.NET Core this will depend on your specific case. For more details you can reference to the following article in the Microsoft documentation: Handle errors in ASP.NET Core
For example, see the solution provided in the following post: After upgrading to .Net 6, system.web no longer contains HttpException
I tried to create a class library for .NET Core, but there is only .NET or .NET Standard library option
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 an ASP NET MVC project with net471 target framework but I found nuget reference to Microsoft.AspNetCore.* or Microsoft.EntityFrameworkCore.*
It's correct? What problems can it entail?
It depends. First, I'm not sure if you're using terminology correct. Do you have an ASP.NET MVC 5 project or an ASP.NET Core project? If the former, then yes, it's very much incorrect. If the latter, then no it's fine, depending on the ASP.NET Core version.
.NET Framework 4.7.1 implements .NET Standard 2.0, which .NET Core 2.2 is also compatible with. Therefore, you can include ASP.NET Core 2.2 packages in a .NET Framework 4.7.1 project. Despite the name, an ASP.NET Core web app doesn't have to actually run on .NET Core. However, ASP.NET Core 3.0 or EF Core 3.0 would not work because those depend on .NET Standard 2.1, which no version of .NET Framework implements (and probably never will).
I am using VS Pro Update 3
I have been following the guide here: https://www.hanselman.com/blog/HowToReferenceAnExistingNETFrameworkProjectInAnASPNETCore10WebApp.aspx
I have 3 existing .NET 4.5.1 Class Libraries, written in VB.NET but I don't think that should matter as it's all on CLR.
My ASP.NET Core project is C#, targeting .NET 4.5.1.
Here is the Framework section of my project.json:
"frameworks": {
"net451": {
"dependencies": {
"WebApp.Api.Services": {
"target": "project"
}
}
}
},
If I add all my VB.NET class libraries using Add Existing Project to my solution and try to add them as project reference, I get the following error:
Project XXX type is unsupported by current project and cannot be added
as a reference
I also tried adding a C# class Library (WebApp.Api.Services), add VB.NET references to that, then add the C# Class Library as a reference to the ASP Core project
Doing this shows the references in Solution Explorer okay, it seems as though I can use types from the C# Class library but I can't use the VB.NET library's types in my code.
I also created a NuGet package, but no luck
I have read that you can create a 'wrapper' project somehow, or Visual Studio can do this automatically.
Has anyone ever tried adding VB.Net projects to ASP Core solution?
A project built for .NET Core cannot use class libraries built for .NET Framework. They are not directly compatible with each other. In fact I'm confused when you say:
My ASP.NET Core project is C#, targeting .NET 4.5.1.
If it's targeting .NET 4.5.1, then it's not actually a .NET Core project.
You should port your class libraries to .NET Standard; that way they can be used by a wide range of compatible frameworks. It is also possible to have a class library target multiple frameworks.
I managed to solve my issue.
The guide here is correct, I had another different issue that I didn't realize.
I found a System.BadImageFormatException error which lead me to the following question Start an asp.net core project as x86 under visual studio 2015
I uninstalled the x94 version of .NET Core and installed the x86 one.
I still could not add references to the VB.NET libraries to the ASP Core project, so my C# services 'Bridge' library was vital.
In my 'Bridge' library I have Models that I can return from my ASP Controllers:
Public BridgeModelA : VB.NETLibrary.ActualModelA
{
…
}
Then extensions
Public static VB.NETLibrary.ActualModelA ToModel(this BridgeModelA)
{
…
}
Although the base members of these models cannot be accessed in the controllers, due to ASP proj not referencing the VB projs, they are returned by the controller with JSON result containing all base members.
This is actually great as it fits in with the design of thin controllers.