I have read some on .net standard e.g. https://weblog.west-wind.com/posts/2016/Nov/23/NET-Standard-20-Making-Sense-of-NET-Again and am still a bit confused on upgrading an existing full framework to .net core 2.0 using standard 2.0.
My question is if a third party library does not support .net standard 2.0 is this an issues.
For example I have an application that uses JSON.net and log4net where the first supports standard 2.0 but second only supports 1.3
Related
I am working on the migration of asp.net app to .net core , I have only list of packages(Not the code) used so need to know that if a package is .Net Standard 2.0 supported then the same package can be used in .net core 3.0?
As this document indicates that:
Net Standard 2.0 supports >= Net Core 2.0.
Net standard itself is compatible with net framework and net core at the same time, you only need to pay attention to the version it supports.
So if your packages support net standard 2.0, they will be installed into Net Core 3.0 without any errors.
I'm using the Microsoft Api analyzer and it gives me the choices of .Net Core 2.0 & .Net Standard 2.0. and the "+ Platform Extensions."
We want our code to run on .Net Standard 2.0 on any server (don't care about phones or tables). So Windows, Linux, etc.
That means .NET Standard - right? If it's .NET Core 2.0 & .NET Framework 4.6.1, but not in .NET Standard, I can't use it. (This is horribly limiting.)
And if we want to put a version up (via NuGet) that includes the platform extensions - how do we define that?
I have a .net Core 2.2 project. This is created using a Webapplication (Model View Controller) template. I can add my .Net Framework 4.7.1 projects into this core project, it compiles, run - and is deployed on my test servers.
1) Then I read about 2.2 End of Life, and I tried to migrate this to 3.1, and I cannot reference .Net Framework 4.7.1 in 3.1 framework. I don't know what is my next step here.
2)I read that I can convert my dll's to .Net Standard and reference - but, how can I do this?
3)These 4.7.1 dll's are shared by .Net Framework projects and core projects, so if I change this to .Net Standard - will my .Net Framework applications work?
4) Also - should I migrate my 2.2 Core projects to 3.0 because of the EOL? Is that mandatory? How will EOL affect audits if I don't migrate?
First, 2.2 is EOL, because 2.1 is the LTS release. You can downgrade to 2.1 if you don't want to jump to 3.x yet, and you'll still have a year or two of support there, I think.
However, 3.x takes the first step towards the new vision of one .NET (.NET 5 for all workflows), so the sooner you can get there, the better. 3.1, specifically, is the LTS release for 3.x, so stick there if you don't want to be forced to upgrade again for a while.
.NET Core 3.x implements .NET Standard 2.1, which is why you can no longer target .NET Framework with that (no version of .NET Framework implements .NET Standard 2.1 and never will). However, .NET Standard 2.0 is supported by both .NET Core (2.x and 3.x) and .NET Framework 4.6.1+. As a result, if you need to share a library between all these targets, you should target .NET Standard 2.0.
As far as converting your existing libraries go, you simply change the target framework to .NET Standard 2.0. That's literally it. Once you do that, some functionality in the library may fail (anything that requires .NET Framework, i.e. Windows-specific APIs). At that point, you either need to rewrite those parts of the library to use .NET Standard-compatible APIs, or use compiler directives to sub-in alternate implementations for .NET Standard 2.0/.NET Core, at which point, you'd have to multi-target the library (i.e. .NET Framework and .NET Standard 2.0 or even specifically .NET Core). When compiling, DLLs will be generated for each specific target, allowing you to seamless reference the same library from projects targeting any of the library targets.
If you're doing anything with ASP.NET Core components in your libraries, you should factor that code out into separate libraries and target .NET Core 3.1 directly there. There's no point in targeting .NET Standard 2.1, as that code will only ever be applicable to .NET Core, anyways. You should also work in the opposite direction. In other words, if there's anything that's only applicable to .NET Framework projects (Web Forms, etc.), then factor that out into separate libraries that will only target .NET Framework. That will allow you to migrate the remaining parts of the library more easily to .NET Standard 2.0.
.NET Standard prescribes an API that all .NET Platforms must implement. What are its versioning rules? Is it breaking.adding, in which 1.4 adds to and remains backward compatible with 1.3 whereas 2.x is not backward compatible with 1.x?
The documentation is not clear on this. Some Microsoft docs indicate pure backward compatibility:
Given a .NET Standard Library version, you can use libraries that target that same or lower version. (emphasis added)
Now that 2.0 is out, the above doesn't seem correct. That being said, the release blog post said:
From a library targeting .NET Standard you’ll be able to reference [libraries targeting] .NET Standard, if their version is lower or equal to the version you’re targeting. (emphasis added)
That same blog post contradicted itself by saying:
In order to allow .NET Framework 4.6.1 to support .NET Standard 2.0, we had to remove all the APIs from .NET Standard that were introduced in .NET Standard 1.5 and 1.6.
Now that 2.0 is out, what are the versioning rules? It appears to be breaking.adding. Where has MSFT documented this?
I've explained this in a bit more detail in our On.NET episode on .NET Standard.
Generally, this is how .NET Standard works:
.NET Standard will version linearly, with the intention of not making breaking changes between versions. In other words, you can think of the API surface of .NET Standard as concentric circles, where higher versions have more APIs.
A specific version of a .NET platform will implement a specific version of .NET Standard.
When choosing a .NET Standard version to target consider this trade-off:
The higher the version number, the more APIs you can use
The lower the version number, the more .NET platforms support it
So why is there this talk about breaking changes? The short answer is because we made a mistake when defining .NET Standard 1.x and didn't take platform reach into consideration. You should ignore .NET Standard 1.5 and 1.6 and avoid taking a dependency on them. If you do that, .NET Standard 2.0 is a strict superset of .NET Standard 1.4.
For more details, read the section .NET Standard 2.0 breaking change: adding .NET Framework 4.6.1 compatibility in my blog post on .NET Standard.
Update. After a lot of community feedback we decided not to perform this breaking change. More details around this decision is listed in the .NET Standard FAQ.
Microsoft provides a number of command line tools for working with asp.net applications. I haven't had any trouble using these tools. One thing that I can not understand though, is the location of these tools.
Even for applications targeting newer versions of .net, these tools are located in the .net v2 directory. On my machine, that's C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727. Why do these tools not exist in the v3.0 or v3.5 directories? And why do the ones in the older directory work on the newer framework?
This is more of an idle curiosity than required knowledge for me, but I would like to know.
Update:
Thanks for the good answers everyone. These answers raise a new question though. I hope you will forgive me for asking it here, since it is so highly related. If .net 3.5 is really just using the CLR from 2.0, why is 2.0 compatible with Windows 2000, but not 3.5? It would seem to me that if the updates in 3.0 and 3.5 run inside the framework of the earlier version, then they must maintain compatibility with the same platforms as the earlier version too. Why is this wrong?
.NET 3.0 and 3.5 are (basically) just library additions to the 2.0 framework.
The addition of .NET 3.0 didn't mean new compilers or a new CLR. Instead, it's three major new libraries: WCF (Windows Communication Foundation née Indigo), WPF (Windows Presentation Foundation née Avalon) and Windows Workflow or WF.
Basically, remember Framework version != CLR Version. If you configured an IIS Application to use .NET 2.0, you're talking about the 2.0 CLR. WCF Applications use the .NET 2.0 CLR with the new 3.0 WCF libraries.
* .NET Framework 1.x = CLR 1.x
* .NET Framework 2.0 = CLR 2.0
* .NET Framework 3.0 = CLR 2.0
* .NET Framework 3.5 = CLR 2.0 + (C# 3.0 | VB9)
Edit:
To answer your second question, .NET 3.0 and 3.5 have new libraries which reference OS-level features like WPF, which isn't available on Windows 2000. If you write an application in 3.5* but only use functionality and libraries that were also available in 2.0, it can still work on Windows 2000.
*by "in 3.5", we mean write it in Visual Studio 2008 under 3.5 but set your Project Target Framework to 2.0. Scott Hanselman talks about doing this to get ASP.NET MVC to work on .NET 2.0.
It is because the core of .Net has not actually been changed since v2.0. MS marketing types were much derided at the time for forcing the naming scheme in use, where .Net 3, and .Net 3.5 are really just adding additional libraries that run on the .Net 2 core.
Check out Scott Hanselman's blog post for more details.
Because .NET 3.0 and 3.5 are applications of .NET 2.0, not complete, standalone frameworks unto themselves. This is further see in the IIS config, where you only have the option to select .NET 1.0, .NET 1.1, and .NET 2.0. You web.config file will include any .NET 3.0 or .NET 3.5 assemblies as these are written, ultimately, with .NET 2.0 code. More details about that can be seen here: http://www.hanselman.com/blog/HowToSetAnIISApplicationOrAppPoolToUseASPNET35RatherThan20.aspx
Of course, that all changes in .NET 4.0 which will be a completely "new version" of the framework.
v3.0 and v3.5 still uses the v2 DLLs for the core files. Most of the changes are additions to the v2 framework as well as a new compiler for 3.5.