This question already has answers here:
What is the difference between .NET Core and .NET Standard Class Library project types?
(13 answers)
Closed 3 years ago.
I want to create a library to use in .Net framework applications and Xamarin applications. But there are 3 framework versions:
.net core
.net framework
.net standart
So I could not decide which version to use my common library.
If I create a .net standart library, does it work in .net framework and .net core.
If I create a .net core library, does it work in .net framework and .net standart.
I am confused about frameworks.
This might help you decide
.Net Standard : Used for building libraries that can be referenced from all .NET implementations, such as .NET Framework, .NET Core and Xamarin
.Net Core : Used for building cross-platform console apps and ASP.NET Core Web apps and cloud services.
So when if you want your library to be supported by all different type of .Net implementations, .Net standard is the way to go.
As you're writing a C# library I imagine you know the difference between a class and an interface. A class is a concrete implementation of some feature set, and an interface defines what features you can expect from an instance that implements it.
Using this as an example, .NET Framework and .NET Core are like classes. .NET Framework is the "classic" implementation, and .NET Core is a newer implementation which has advantages such as being able to run on Linux. If you build a library to target .NET Core or .NET Framework, you are building it to target one of those concrete implementations.
.NET Standard on the other hand is like an interface. Each version of .NET Standard provides a set of features, and different versions of .NET Framework/.NET Core implement different versions of .NET Standard. When you build a library that targets a given version of .NET Standard, you're saying that you can support all of the concrete implementations in the corresponding column of that table.
Deciding what version of .NET Standard to target will depend on what functionality you need to implement your library. More features usually means a higher version and supporting fewer implementations. Fewer features means a lower version and more widespread support.
So many confusing other answers here.
First and foremost it depends on what platforms you are targeting.
is it a generic use library you want share with the world?
is it an application specific library (i.e. reusable code for the same application, i.e. a line of business application) which is to be used on multiple platforms
Case 1
You should go with .NET Standard, since it gives you the most platforms. Which version you use, depends on the features you need.
If you want reach the most platforms, try to target as low as possible (.NET Standard 1.0, it targets .NET Core 1.0, .NET Framework 4.5, Mono, Xamarin iOS 10/Mac 3.0/Android 7.0, UWP 10 and Uniy 2018.1 and all newer versions of these).
You can see the exact .NET Standard Matrix in the provided link.
If you need specific API you have to target a higher version, such as .NET Standard 2.0 which a lot (~22k new APIs from .NET Framework have been ported to .NET Core 2.0 from 1.1) APIs than .NET Standard 1.1.
This may not allow you all APIs (no WPF/WinForm specific apis) but in generic use reusable libraries this shouldn't be an issue.
Case 2
Here, you can also apply Case 1 tips, if possible.
If that doesn't cover your required Apis and you know you don't want target .NET Core or Unity, you can still use the old styled PCLs: Portable Class Library.
They are a more complicated versions of .NET Standard (kinda a predecessor of .NET Standard), where depending on which platform you target the API surface shrinks to only allow APIs to be used which run on all these platforms.
It's not recommended these days to use PCLs, since .NET Standard is preferred and more easy (for library authors) to use and target multiple platforms.
Last but not least, if you really need some feature only on Windows and .NET Framework (or you don't care for .NET Core), you can still cross-target, i.e. have a .NET Standard 2.0 for all platforms and add specific APIs only to net45 target and preprocessor instructions (#if NET45/#endif).
This compiles into two libraries, one for netstandard2.0 and one for net45 (.NET Framework 4.5).
Related
I wanted to know the difference between the two packages and if it had anything to do with .NETCore and NETStandard and compatibility. I found this:
The NETStandard target framework is an abstract target framework that represents API surface of many frameworks and platforms. As such NETStandard assemblies can run on any platform that supports the NETStandard targeted by that assembly, for example: .NET Desktop, Windows Phone, Universal Windows Platform applications, .NET Core applications, etc. NETCoreApplication is a concrete target framework that represents a single platform with both API surface and implementation. .NET Core applications are runnable on their own. .NETStandard libraries must be published-for or consumed-by a specific concrete target framework to be used in that type of application.
on https://masteringalm.github.io/framework/2018/07/24/NetStandardvsNetCoreApp-Project-Types.html
But I’m not really sure how to use this to describe the differences between the two packages. I saw a post on this link: What's difference between .NetCoreApp and .NetStandard.Library?
Where it said:
NetCoreApp is a platform and .NetStandard.Library is a library supposed to be cross platform (portable class library) for various .NET platforms runtimes.
I think this connects to differences between the two specific packages mentioned in the question header, but could anyone describe the differences between the packages in a not so convoluted way?
.net standard
Each implementation of the managed framework has its own set of Base Class Libraries. The Base Class Library (BCL) contains classes such as exception handling, strings, XML, I/O, networking, and collections.
.NET Standard is a specification for implementing the BCL. Since a .NET implementation is required to follow this standard, application developers will not have to worry about different versions of the BCL for each managed framework implementation.
Framework Class Libraries (FCL) such as WPF, WCF, and ASP.NET are not part of the BCL, and therefore are not included in .NET Standard.
The relationship between .NET Standard and a .NET implementation is the same as between the HTML specification and a browser. The second is an implementation of the first.
Hence, the .NET Framework, Xamarin, and .NET Core each implement .NET Standard for the BCL in their managed framework. Since the computer industry will continue to introduce new hardware and operating systems, there will be new managed frameworks for .NET. This standard allows application developers to know that there will be a consistent set of APIs that they can rely on.
Each .NET version has an associated version of the .NET Standard.
.NET Core is a free, cross-platform, open source implementation of the managed framework. It supports four types of applications: console, ASP.NET Core, cloud, and Universal Windows Platform (UWP). Windows Forms and Windows Presentation Foundation(WPF) are not part of .NET Core.
Technically, .NET Core only supports console applications. ASP.NET Core and UWP are application models built on top of .NET Core.
Unlike the .NET Framework, .NET Core is not considered a Windows component. Therefore, updates come as NuGet packages, not through Windows Update. Since the .NET Core runtime is installed App-Local, and applications are updated through the package manager, applications can be associated with a particular .NET Core version and be updated individually.
For more information visit https://www.infoq.com/news/2017/10/dotnet-core-standard-difference/
Overly simplistic, but think of .NET Standard as a library that runs on any platform that can run .NET. This means it can run on Linux, Mac, Windows, etc. .NET Core is a minimalistic version of the "framework", so you can keep your your apps as small as possible and only add what you need. Core means only the core functionality that is absolutely required for an app to run.
Why is standard and core different? It is largely because the functionality of .NET on other platforms started open source with someone other than Microsoft. As such, the features have lagged behind .NET. The name of the .NET "framework" on other platforms was Mono. As some point .NET Core may well replace standard, but certain things have to get to the same level.
I imagine some purist will disagree with my oversimplification, but it is an easy way to get your head around the libraries.
As for what specifically is different between the two (or "what is missing from standard to be equivalent to core") - I am not sure. I am sure it can be looked up. In many cases, I have found Core works fine, such as dockerizing the application (Yeah, I made the word "dockerizing", but meaning running in a Docker container). The problems are when you run some package that cannot be handled in "Mono".
When it comes to packages you add into the standard or Core (Nuget anybody?), where there is a difference deals with one having features that cannot run in standard.
I'm working on a class library project whose Target Framework property is set to .NET Standard 2.0.
Based on the documentation, I understand that my code will compile in such a way that it will be compatible with .NET Core 2.0 and .NET Framework 4.6.1. Is that correct?
Does this mean that I can use (and mix together) types and assemblies from .NET Core 2.0 and .NET Framework 4.6.1 in my project? I'm also unsure about which pages from the Microsoft documentation apply to my project.
Would I be correct in thinking that both the following documentation pages reference the types and assemblies that I'll use in my project?
.NET Core 2.0
.NET Framework 4.6.1
I tend to think of .NET Standard as a specification of APIs that are supported for different platforms and .NET versions. It’s a “least common denominator” of APIs supported for different platforms. A platform might be .NET Core, .NET framework or Unity.
So let’s say your library is Standard 1.0 this means that it can run on a wide range of platforms, but the number of APIs specified in that standard is limited compare to the full .NET Framework or .NET Core.
It’s important to understand that .NET Standard is just a “standard” or a promise of supported APIs for a given platform, you could write an OS for a microwave that supports .NET Standard 1 (implements all API in the standard) and the a class library for .NET Standard 1 work run on that microwave
Have a look at the docs, they have a great table that explains this: https://learn.microsoft.com/en-us/dotnet/standard/net-standard
You can use all the things, you just have to setup your project correctly. Limitations will be that .NET Core objects/methods/etc. will not be directly interoperable with .NET Framework. You will have to work through .NET Standard for indirect interoperability.
This article explains how to target both in the same .sln:
.Net Framework and .Net Core in same solution
This article helps you understand .NET Standard in relation to .NET Framework and .NET Core. Essentially, .NET Standard is base library which both .NET Core and .NET Framework sit on. .NET Core and .NET Framework are completely separate libraries, however they are both interoperable through .NET Standard.
http://www.codedigest.com/quick-start/9/what-is-netstandard
I have a project that is targeted to .Net Framework 4.8. Now, we need to use a 3rd party dll. The problem is that the dll is targeted to .Net Standard 2.1.
Is there a way to use this dll in the .Net Framework 4.8 project?
I added the dll, get this error:
Could not load file or assembly 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
I searched, seems it should work directly. Maybe I need to add a reference? Not sure what needs to do now.
Thanks
You cannot consume a .Net Standard 2.1 assembly in any .Net Framework Version because the .NET Framework (even the last ever version, 4.8) does not implement .Net Standard 2.1.
The .Net Standard .NET implementation support matrix at https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-1 does not contain an entry for 2.1 under "Framework". Although very unlikely, the support matrix might change in time; this was the supported list at the time of writing.
More details on the decision by MS: https://devblogs.microsoft.com/dotnet/announcing-net-standard-2-1/
Extract:
Given many of the API additions in .NET Standard 2.1 require runtime
changes in order to be meaningful, .NET Framework 4.8 will remain on
.NET Standard 2.0 rather than implement .NET Standard 2.1. .NET Core
3.0 as well as upcoming versions of Xamarin, Mono, and Unity will be updated to implement .NET Standard 2.1.
Library authors who need to support .NET Framework customers should
stay on .NET Standard 2.0. In fact, most libraries should be able to
stay on .NET Standard 2.0, as the API additions are largely for
advanced scenarios. However, this doesn’t mean that library authors
cannot take advantage of these APIs even if they have to support .NET
Framework. In those cases, they can use multi-targeting to compile for
both .NET Standard 2.0 as well as .NET Standard 2.1. This allows
writing code that can expose more features or provide a more efficient
implementation on runtimes that support .NET Standard 2.1 while not
giving up on the bigger reach that .NET Standard 2.0 offers.
Solution:
The easiest way would be to convince the 3rd party to backport/multi-target to support netstandard2.0 as well. Alternatively, you can switch to targeting .Net 6 (LTS), .Net Core 3.1 (LTS), or Mono instead of Framework 4.8 in your project.
UPDATE:
Another possible workaround:
You might also attempt some trickery with .NET Framework compatibility mode. I had no idea you could do this. You could, for example, make a "wrapper" project that targets standard and references both your .Net Framework 4.8 code and the 3rd party library, unless the 4.8 part uses WPF - perhaps there are other pitfalls in unsupported scenarios as quoted below. It sounds convoluted to me, but if you have no other option, it might be worth a shot. From the same original site:
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.
(*) - Also .Net Core (elsewhere in the document/page)
Compiling a .NET Standard project gives me a dll. .NET Standard projects can also have dependencies, so the code is being compiled into something. How is this different than what is compiled when a .NET Framework or .NET Core project.
Am I just "extending" the implementation of .NET Standard when I create a class library?
Everything I've read compares .NET Standard to an interface and .NET Core/.NET Framework to implementations of some version of those interfaces.
My question is, if that is true, how can I create an actual .NET Standard library. and why can't I reference a .NET Standard library that is using any version of .NET Standard (ex: .NET Framework 4.5 should be able to use a .NET Standard 2.0 class library since it is clearly already being compiled)?
As far as I understood it, when you compile against .NET Standard, you are effectively compiling against mockups, i.e. assemblies that contain the public interface that is defined by .NET Standard but no implementation. At runtime, these mockups are replaced by assemblies that contain type forwards to the actual implementation. The replacement works because the mockups and these type forwarding assemblies have the same signature. However, these type forwarding assemblies do not exist for every version of the .NET Framework, actually only for the very recent versions.
According to Microsoft`s definition:
.NET Standard is a set of APIs that all .NET platforms have to
implement.
Note that, the .NET Standard is frozen. New APIs becomes available first in .NET Core or .NET Framework, and then after being review by a committee, the may be added in .NET Standard as well.
Personally according to the above definition if I wanna develop a general library that I will use it during a product development lifecycle then I would prefer to make it more framework independent by using .NET Standard.
More you can find here.
Say I have a solution with several projects included. One of projects is Main (where general code and APIs are placed) and the rest are kind of extensions (Extension1, Extension2, Extension3) for the Main and use third-party libraries. Now I'm making the solution compatible on both Full Framework and .Net Core Framework.
The solution had already had conditional building process depending on target framework before I started adding support for .Net Core, so I have no problems with conditional building yet.
The problem what I do have is that part of third-party libraries is not compatible with .Net Core yet. That makes a part of the extensions incompatible with .Net Core. The only option that comes to my mind is to have separate solutions and code bases for full framework and .Net Core Framework. BUT I would like to have same code base in both cases because my code is pretty compatible with both frameworks and otherwise it would be such a pain in the neck to support.
Is it possible to have only one solution for that case and be able to build (Main + (Extension1, Extension2, Extension3)) projects for full framework and (Main + (Extension1, Extension2)) for .Net Core Framework? If it's not, what options do I have?
Thank you all in advance
You want to be looking into .NET Standard - I'd also take a look at the videos put out by Immo Landwerth about it.
The tl;dr is that .NET Standard lists the APIs and methods which you can expect a .NET application (Framework, Core, WPF, Xamarin, etc.) to have access to. Higher version numbers of the standard include more APIs but reduce the number of frameworks you can use (Framework, Core, WPF, Xamarin, etc.).
Here's a visual of how .NET Standard is adopted and supported by the different frameworks.
Along the top are the versions of .NET Standard, and down the left are the versions of the frameworks. Using this chart, you can see that .NET Standard 2.0 is supported by:
.NET Core 2.0
.NET Framework 4.6.1
Mono 5.4
etc.
This means that any application which targets any of those frameworks will have access to the APIs listed in .NET Standard 2.0.
In your example, you could have all of your business logic in .NET Standard compatible libraries (regardless of whether they are Framework or Core) and have two separate Main projects (one for Framework and one for Core).
This could be done with three separate solutions:
One for your .NET Standard class libraries
One for your .NET Framework Main (which includes the .NET Standard class libraries)
One for your .NET Core Main (which includes the .NET Standard class libraries)
You could also build the .NET Standard class libraries as a NuGet package (with or without hosting them externally) and pull them into your two (.NET Framework and .NET Core) Main solutions.