I want to ask you difference of .net infrastructure and framework. When i try to create class library project, visual studio offer me infrastructure like .NET Framework 4.7.2, .NET Framework 4.8 etc versions. But when i try to create console application it offers me framework like .NET 6, .NET 7 etc. versions.
That's not true. If you select a project template that targets .NET Framework then you will be prompted to select a version of the .NET Framework. Those project templates have ".NET Framework" in the name. Those project templates that do not specify that they target .NET Framework will target .NET Core, so you will be prompted to select a version of .NET Core. .NET 5 and later are based on .NET Core. You can create class library projects targeting either .NET Framework or .NET core and you can do the same for Console application projects.
Because .NET Framework is not being developed beyond version 4.8.x, they have dropped the "Core" from the name, because it's the only game in town. .NET 5 was supposed to be a merger of .NET Core and .NET Framework, which basically means an evolution of .NET Core that adds more features like those of .NET Framework.
Related
I have two C# console applications. In one project, under Properties -> Application -> Target Framework, I can choose .NET Core 1.0 through .NET Core 3.1 and .NET 5.0. In a different project, I have none of those choices. Instead I have .NET Framework 2.0 through .NET Framework 4.7.2. (In addition, the csproj files of the two projects look very different.) If I wanted to change one project to a framework only listed for the other, is that possible?
This page showed that .NET Core is a cross-platform, open-source successor to .NET Framework.
https://learn.microsoft.com/en-us/dotnet/core/introduction#net-core-and-net-5
If you want to change .NET Core project to .NET Framework project, you can refer to this page.
https://learn.microsoft.com/en-us/dotnet/core/porting/
https://learn.microsoft.com/zh-cn/dotnet/architecture/modernize-desktop/example-migration
By the way, VS2022 can modify the target framework directly in the properties.
You can also refer to this.
How to change .NET version in Visual Studio 2019 to .NET Framework 4.7.2?
We have old project, which back end written in .NET Core 2.2 and front in .NET Framework 4.0 (WPF), so i want to create and use common library for .Net Framework 4.0 project and for .Net Core 2.2 project. Is it possible what i use .NET Standard for this?
Because in documentation (https://learn.microsoft.com/en-us/dotnet/standard/net-standard) written, minimum version of .NET Standard is .NET Standard 1.0 and supports .NET Framework 4.5.
How i can solve this problem?
In one of my .NET Framework projects, I introduced a new .NET Standard 2.0 project. This project has dependencies on some existing .NET Framework projects. I was wondering if this is right to do.?
The reason I added a .NETStandard project is that we have plans to move the whole repository to .NET Core / Standard. Hence I thought, the new project we add can target .NET Standard. With .NET Standard project I get the new SDK style project file, package references, etc by default.
The consuming application is still .NET Framework.
Do I have to retarget the new project to .NET Framework 4.7.2 so that the project will have the above SDK style project file and package references but targets .NET Framework 4.7.2 now. It will then be as easy as changing the target framework when we move to .NET Core?
Depends on your purpose of introducing the Standard 2.0 project. Normally, you make a Standard when you need it to be accessible both from .NET Framework and Core. In your case, your Standard project won't be operable from Core under macOS or Linux.
Yes, this can be done.
https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-0
.NET Framework compatibility mode
Starting with .NET Standard 2.0, the .NET Framework compatibility mode was introduced. This compatibility mode allows .NET Standard projects to reference .NET Framework libraries as if they were compiled for .NET Standard. Referencing .NET Framework libraries doesn't work for all projects, such as libraries that use Windows Presentation Foundation (WPF) APIs.
This is necessary as an intermediate step for some projects, but in order to get to your final goal you will of course have to go all in on .net core which will require updating those projects not to use framework or they will crash at runtime.
I'm building an ASP.NET Core Web API project. I will be heavily using EF Core with the connection with SQL Server. I want to organize the project around 3 main tiers: Core/Logic/Domain, Data/Infrastructure and Web/API.
Web/API will be definitely a .NET Core project, but I'm struggling with the decision whether Core and Data projects should be .NET Core library or .NET Standard library.
My question is, will I lose any features or anything while building my data persistence in .NET Standard library?
For a class library, the target framework simply specifies a compatibility layer. The ultimate functionality comes from the target framework of the project that references the class library.
For example, let's say that you create a .NET Standard library, and then you include that in a .NET Framework project. Everything you do happens on .NET Framework, and for all intents and purposes you could've targeted .NET Framework from your class library as well. The choice of .NET Standard simply says that you're going to use APIs from some .NET Standard-compliant target. That's all. As a result, the functionality of something like EF Core, ultimately depends on what you drop the library into, not what framework your library targets.
As to whether to choose .NET Standard or .NET Core as the target framework for your library, simply: use .NET Standard unless you have a good reason not to. If you target .NET Standard, you can drop it into any project that targets any framework that is compatible with the version of .NET Standard your library targets. If you choose .NET Core, you can only use the library in .NET Core projects.
Things get a little murkier when you start looking at .NET Core 3.0, though. You can technically target .NET Standard 2.1 and get all the goodness of .NET Core 3.0, but nothing but .NET Core 3.0 actually supports .NET Standard 2.1. You can target .NET Standard 2.0, but then you're stuck with .NET Core 2.2. In other words, if you want to use .NET Core 3.0, right now, there's no functional different between choosing .NET Standard 2.1 or .NET Core 3.0 as the target framework of your library. In either case, it will only work in .NET Core 3.0 projects.
Adding even more confusion, Microsoft is moving the next version of everything under the .NET 5 umbrella. What becomes of .NET Standard at that point hasn't been discussed, by I'd imagine it largely goes away. Once there's a .NET 5, any project can target .NET 5 and be used by any other project that targets .NET 5. That's still a ways off, though. The reason I bring it up, is that if you want to use .NET Core 3.0 today, there's not much point in targeting anything but .NET Core 3.0. Most of the stuff in .NET Standard 2.1 is not back-portable to things like .NET Framework and Unity, so those will never be on .NET Standard 2.1. The path forward for those frameworks is making them .NET Core compatible, to eventually end up with .NET Core 4.0, which Microsoft will call .NET 5.
Long and short, the best performance and features are with .NET Core 3.0, as long as you can go 100% .NET Core 3.0, then that's what you should target. If you need to use your library in something like an Xamarin or .NET Framework app, then stick with .NET Standard 2.0.
From the .NET Standard Microsoft Docs
The .NET Standard is a formal specification of .NET APIs that are intended to be available on all .NET implementations.
From the .NET Core Microsoft Docs
.NET Core is an open-source, general-purpose development platform
What this means in relation to your question.
Creating a .NET Standard library, you would be able to pull that library into a .NET Core project or a .NET Framework project assuming that the .NET Core/Framework project would adhere to the same .NET Standard version of your library or greater. So, the .NET Standard library would give you more flexibility regarding the projects you would be able to pull that library into(good if this needs to be pulled into legacy applications running on .NET Framework >=4.6.1 as well as new applications that would be written in .NET Core).
The only hiccup I've encountered with this approach is regarding migrations. If you want to use EFCore Migrations through the dotnet ef commands, it expects you to target a project with a .NET Core version. So, if you create your DbContext in the .NET Standard library and want to create migrations from it, you will either have to give it a startup project that is a .NET Core project or implement a 'Design-time DbContext Creation'. As an aside, this last option does have a few limitations, one of which is documented in an issue on GitHub.
I have an application targeting .NET Framework, and now I need to develop a library in .NET Core.
I plan to put both projects in the same solution and add the .NET Core library as a reference in the .NET Framework project.
Can this be done? If the answer is yes, how can this be done?
There is an article published in April 2017 on how to support both runtimes from the same solution:
https://learn.microsoft.com/en-us/dotnet/core/porting/project-structure
It boils down to 2 methods:
Having both frameworks configured in the same project (e.g. *.csproj):
Replace existing projects with a multi-targeted .NET Core project.
Having a separate project for each framework:
Keep existing projects and create a .NET Core project.
We are actively discussing which way to go in pythonnet, since the project supports .NET Framework on Windows and Mono on Linux/OSX. Now we are adding cross-platform pythonnet support:
https://github.com/pythonnet/pythonnet/pull/518