Currently trying to learn about the .NET Platform Standard I've found myself quite confused about the idea of "different platforms".
I'll try to make my point clear. What I currently now about the .NET Framework is that .NET is roughly speaking made up of the CLR, the BCL and supporting software to boot the CLR and provide the interface between the virtual machine and the underlying OS.
So when we code using the .NET Framework we indeed target some version of the framework because the types we are using from the BCL come with the framework and so depend on the specific version.
Now, .NET Core is quite different as I understood. It is not all packed together like that. We have the CoreCLR which is a lightweight VM to run the IL, the CoreFX which are the libraries properly organized as NuGet packages and we had up to now the DNX/DNVM/DNU which provided the supporting stuff like booting the CoreCLR and interfacing with the OS.
Anyway, despite if we install the framework on Windows 7, Windows 8 or Windows 10, we code against the framework.
Now, on the .NET Platform Standard spec we see the following definition:
Platform - e.g. .NET Framework 4.5, .NET Framework 4.6, Windows Phone 8.1, MonoTouch, UWP, etc.
Also we see after that a list of platforms, which includes
.NET Framework 2.0 - 4.6
Windows 8
Windows Phone 8.1
Silverlight 4, 5
DNX on .NET Framework 4.5.1 - 4.6
DNX on .NET Core 5.0
Now this confuses me completely. I always though: we code against the .NET Framework and the framework is the framework no matter what.
But here we have these platforms which includes the .NET framework as just one of many platforms. We have for example Windows 8, but wait a minute, running .NET on Windows 8 is not just the same thing as running .NET on any other OS? Why it is separate from the .NET Framework 2.0 - 4.6 platform?
We also have DNX as a specific platform. This makes me wonder: the platform is that "supporting stuff" related to booting the Virtual Machine and providing the interface with the OS? Or the platform includes the Virtual Machine?
Anyway, as can be seen I'm quite confused. What are those platforms indeed and how this relates to my current understanding of the .NET Framework? Also, why .NET Framework 2.0 - 4.6 is described separetely? Isn't everything described here some version of .NET Framework unless .NET Core?
we code against the framework.
Well, sure you are. When you manipulate strings in your code then you'll always use System.String. And it (almost) always behaves the exact same way with the exact same methods and properties.
But displaying the string does have implementation details that you cannot really ignore:
If you want to show it in a Unix terminal on Linux or OSX then you need to target Mono or CoreCLR, the framework implementations that can run on such operating systems.
If you want to show it in a Windows Store app (aka WinRT, aka Windows 8, aka UWP) then it is actually a HSTRING under the hood, an very well hidden detail that you don't have to worry about. But does require an UI gadget, like Windows.UI.Xaml.Controls.TextBlock, a class that is highly specific to WinRT
If you want to show it in a browser then you need to target ASP.NET or Silverlight, framework hosts that were optimized to run on a web server or as an add-in for a browser.
If you want to show it on a device that is powered by a small lithium-ion battery, like a phone, then you'll inevitably have to deal with a framework version that was optimized to use as little power as possible. That does affect the code you have to write, there is a huge difference between code that burns 100 Watts and code that keeps a tiny battery alive for 8 hours. Nothing you can directly see, beyond the need to use async/await a lot, but certainly something that affected the runtime very heavily. Targeting Xamarin or WinRT is required.
If you want to show it on any operating system then you do need to target a framework version that does not use the kind of tricks that .NET uses on Windows to have an EXE launch the CLR virtual machine. That requires dnx.exe, just like you'd use java.exe or python.exe for programs written in Java or Python.
It would be lovely if those implementation details did not matter. But not the way it works in practice, as .NET proliferates and becomes available on more and more devices and operating systems it inevitably also becomes more convoluted. Choose your intended targets early, it is important.
There are many Frameworks (.NET Framework, WinRT, UWP, Silverlight, .NET Core, Windows Phone, Mono, Micro Framework und the old Compact Framework) not just only the .NET Framework.
The new way is to program against a platform standard which supports one or more of this frameworks. The platform standard defines an API which matches one or more frameworks. This means if your application supports platform standard 1.1 you will probably support almost all frameworks. Platform standard 1.4 will support .NET Framework 4.6.x and .NET Core only
Have a look at this document: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
Now this confuses me completely. I always though: we code against the .NET Framework and the framework is the framework no matter what.
No, there are actually plural .NET frameworks or platforms as you like to call them. Prior to .NET Standard, you used to target a single framework (maybe the full one, currently at version 4.6.3, if you develop web applications or windows services). DLLs targeting a framework are not compatible with another one. I.E. a DLL developed for the full .NET framework cannot be executed on Windows phone 8.1.
These frameworks actually implement a quite small common set of librairies, but also specific libraries for dealing with the platform they are intended for. I.E. libraries for managing a web server hosted on IIS in the full .NET framework, or functions for dealing with a mobile phone in the windows phone 8.1 framework.
Before .NET Standard was the PCL
There was although a workaround, called PCL which stands for "Portable Class Libraries". By using only the small common subset of methods/assemblies in two or more .NET frameworks, one could develop a library that could be included in projects targeting different frameworks. For instance, PCL profile 37 means you want your library to be usable in .NET Framework 4, Silverlight 5, and Windows 8 projects.
Please have a look at this for a list of PCL profiles and their compatibilities (I don't know if it's exhaustive): http://danrigby.com/2014/05/14/supported-pcl-profiles-xamarin-for-visual-studio-2/
Now what about .NET Standard ?
The goal with .NET Standard is to simplify this and get rid of PCLs. Roughly, .NET Standard defines a contract (a set of classes and methods), that will be implemented by all .NET frameworks. If you develop a library that targets .NET Standard, you're sure it can run on all .NET frameworks. It's the basic idea/goal behind it (even though it's a bit more subtle).
Have a look at this for the exact compatibility: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/#user-content-whats-new-in-net-standard-20
If you look at the compatibility table, you'll see that a library targeting .NET Standard 1.6 is usable as is (no need to recompile it) in .NET Framework 4.6.3 and .NET Core 1.0 applications.
In other words, we can say that .NET Framework 4.6.3 and .NET Core 1.0 both implement the .NET Standard 1.6 contract: its classes and methods.
If you also want your DLL to be usable in a windows phone 8.1 project, you'll have to target .NET Standard 1.2, which offers less functions than .NET Standard 1.6 (no System.Net.Sockets for instance).
See here for a list of available namespaces in each version of .NET Standard https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#user-content-list-of-net-corefx-apis-and-their-associated-net-platform-standard-version
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.
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).
Currently I'm working on an WPF app that will be packaged as UWP app so I can publish it in Windows Store. I'm following this video in making this happened (https://www.youtube.com/watch?v=fJkbYPyd08w)
Now, I want my application to implement Subscription Base service. So I found this link: https://learn.microsoft.com/en-us/windows/uwp/monetize/enable-subscription-add-ons-for-your-app
But it seems that I can't add UWP Windows.Services.Store Namespace library into my project. I try to seek in Nuget without success.
Where can I get this library? How to use it in WPF?
Thanks
You only need to add the Microsoft.Windows.SDK.Contracts NuGet package to your project. For details, see this blog post.
tl;dr: WPF runs on .NET Framework, UWP on .NET Core. .NET Framework and .NET Core cannot directly share code with each other, for this you require .NET Standard class libraries.
I see that you're quite new to C#, so I'll try to keep it short and simple.
.NET is a lot more than people think it is, what most people mean by .NET is the .NET Framework. What it actually is, is the Common Language Infrastructure (CLI) and the Common Intermediate Language (Historically MSIL now CIL), on top of which you have the .NET Standard, this is a base collection of classes that all .NET implementations must have and is the way of sharing code between different Frameworks.
Another layer up you get the Frameworks. .NET Framework being the most popular but also the oldest, it features ASP.NET, WinForms, WPF and more.
The .NET Core is the Framework form Microsoft featuring Cross-Platform support, so your programs can run on Windows, Linux and OS X, UWP runs on the .NET Core.
Here is a great diagram visualizing this
Note: In the upcoming release of the .NET Core 3.0, you will be able to create WPF applications running on windows (WPF will not be supported on Linux or OS X)
I'm porting an application from .NET 4.0 to support both .NET 4.6 and .NET Standard 1.6 to be used as a cross-platform MSBuild task.
This application makes use of all kinds of stuff that we took for granted as Windows developers. One of them is the Registry and RegistryKey classes. That is no longer available in .NET Standard 1.6.
What can I do to make use of it on any Windows platform (.NET Framework and .NET Core) and ignore it on other platforms (.NET Core only)? I have compiler symbols defined for each target framework, so I can #if out the specific code. But currently the two classes are unknown for the .NET Standard target, with red underlining.
.NET Standard 1.6 (and apparently also 2.0) have no support for accessing the Windows registry. So there are only two options:
Call reg query with appropriate arguments and parse its output. This seems like a complicated task so I didn't investigate that.
P/Invoke the Windows API functions RegOpenKeyEx, RegCloseKey and RegQueryValueEx. Here's the code file I use for that: https://gist.github.com/ygoe/bb776fac530176b08519a5314d53fcb6
I'm a bit confused about targeting .net 4.0 app to run on windows 8.x. In my understanding, windows 8.0 comes with 4.5 and windows 8.1 comes with 4.5.1. So my question, if I build a WinForms or WPF client app targeting c#/.net 4.0 (in Visual Studio Project settings) and of course only using .net 4.0 features (i.e, no features from .net 4.5.x), then will this app run fine on windows 8.x without having install .net 4.0 framework (that is, only relying on what comes installed with OS)? Basically, I'm trying to avoid forcing end user to install .net 4.0 framework on their machine before running the app.
Looking at DLLs properties of various Microsoft DLLs (e.g., System) they show same runtime version when targeting either .net 4.0 or .net 4.5.x --> v4.0.30319. So my understanding here is that 4.0 and 4.5.x are targeting same clr runtime version So, my .net 4.0 app should run fine???
From ref here (http://msdn.microsoft.com/en-us/library/bb822049%28v=vs.110%29.aspx), it says .net 4.0 can't even be installed on win8.x.
In my tests, targeting .net 4.0 and running on clean install of win8.1 seems to work fine (without having to install anything else) but looking for advice on gotchas.
Thanks.
Note that the .NET framework is intrinsically backwards compatible - .NET 4.5 will execute .NET 4.0 code just fine. This can be seen even within a solution in that a .NET 4.5/4.5.1 project can reference an older .NET project without incident. This includes .NET 4.0, as well as earlier versions.
In addition to the backwards compatibility, .NET 4.5 does run on the CLR 4.0 - 4.5 is simply a library and compiler expansion.
Possible gotchas
This emphasis on backwards compatibility is why we almost never see functions disappear from the .NET Framework, just get marked [Obsolete]. it's a good idea to check if any functions you use have become Obsolete, though this is rare and such functions usually continue to work as expected.
Windows 8 does NOT like Drive mapping, and will demand that you use UNC paths if you application touches any networks drives.
Windows 8 can be far more aggressive with requiring Admin privileges to run, up to and including needing to explicitly start VS as admin when trying to compile a program which outputs to C:\Program Files\...
Final note: ALWAYS test your application on the targeted platform before releasing to users.
Per this question:
.NET Framework 4.5 was released on 15 August 2012., a set of new or improved features were added into this version. The .NET Framework 4.5 is only supported on Windows Vista or later. The .NET Framework 4.5 uses Common Language Runtime 4.0, with some additional runtime features.
I would say then that by virtue of having .NET 4.5 installed you will also always have .NET 4.0 installed. I don't think this should be an issue then!
From the link you posted:
Each new version of the .NET Framework retains features from the previous versions and adds new features.
Also from that link:
The .NET Framework 4.5 is an in-place update that replaces the .NET Framework 4 on your computer, and similiarly, the .NET Framework 4.5.1 4.5.2, and 4.6 Preview are in-place updates to the .NET Framework 4.5, which means that they use the same runtime version, but the assembly versions are updated and include new types and members.
So, if a system has 4.5, it will be able to run apps targeted for 4.0 as well. The fact that some versions cannot be installed most likely only means that they are already included from the start.