27

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?

user1620696
  • 10,825
  • 13
  • 60
  • 81
  • There is no *"virtual machine"* in .NET. – IInspectable Feb 16 '16 at 01:26
  • 3
    @IInspectable http://blogs.msdn.com/b/brada/archive/2005/01/12/351958.aspx "So the bottom line is that the CLR and JVM are in the same class whether you call that class of software “virtual machines” “execution engines” depends on your perspective." – Rob Feb 16 '16 at 01:37
  • 2
    I always thought about the CLR as a sort of Virtual Machine. A piece of software which acts as a sandbox on which the application runs. We give to this VM the IL bytecode and the included JIT compiler makes the native code and runs it on that special sandbox. Although I have never studied the CLR in full detail, the docs on GitHub describe it as "a complete, high level virtual machine designed to support a broad variety of programming languages and interoperation among them". This made me believe my rough understanding was reasonable. – user1620696 Feb 16 '16 at 01:42
  • The ".NET Framework" in this documentation refers to the non-core, non-opensource, .net that you install machine wide via an msi installer. It includes the gac (c:\windows\assembly) and compilers etc (c:\windows\mictosoft.net\framework64\vX.X\) – Richard Szalay Feb 16 '16 at 01:44
  • Yes @RichardSzalay, I guessed that by the version. The docs refer to it as .NET Framework 2.0 - 4.6. But still, the docs consider it to be a platform different than Windows 8. But to run a .NET app on Windows 8, or whatever OS, we needed to install the corresponding .NET Framework right? So in the end of the day we would be running on top of .NET Framework itself. I do understand splitting .NET Full and .NET Core, but I don't get the idea with all these platforms. – user1620696 Feb 16 '16 at 01:47
  • It's my understanding that the runtime is different for "metro" and windows 10 apps, but I'll leave the answer to someone with more authoritative information. – Richard Szalay Feb 16 '16 at 02:04
  • @user1620696 in that document when it refers to Windows 8/8.1/10, it means the Windows Store apps/UWP, not the .NET Framework on desktop. – Lex Li Feb 16 '16 at 04:01
  • I think I'm getting it now @LexLi. So each platform is made of a "virtual machine" (like the CLR) together with supporting software for booting the virtual machine and interfacing with the OS and a base set os class libraries like the BCL? So those verticals which appeared on docs introducing .NET Core are the platforms and each of them has a different runtime environment with a different base set of libraries? – user1620696 Feb 16 '16 at 12:43
  • @Rob: .NET code is compiled to native code, running on physical hardware. Nothing is being virtualized (besides the usual native virtualization like virtual memory). And .NET Native removes the need for JIT compilation, essentially producing a native binary. It's pretty hard to justify the term *"virtual machine"*, unless you are calling the Win32 subsystem *"virtual machine"* as well. I wouldn't. – IInspectable Feb 17 '16 at 22:54
  • @IInspectable .NET code compiles to IL, not native code (though I concede there may be tools which do compile to native code, it's not the typical case). – Rob Feb 17 '16 at 22:56
  • @Rob: IL code is **always** compiled to native code, before it gets executed. There is no virtual machine state that gets updated (as is the case with Java). IL is never executed. It's just the source. And .NET Native is the default in the Windows 10 Store. – IInspectable Feb 17 '16 at 22:58
  • @IInspectable Did you read the article I linked? – Rob Feb 17 '16 at 22:59
  • @Rob: Yes. How does that change anything I said, though? IL **never** updates virtual machine state. It gets compiled to native code. There is nothing abstract about the CLR. – IInspectable Feb 17 '16 at 23:03

3 Answers3

7

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thanks for the answer @HansPassant. So those platforms are the verticals which appeared on docs introducing .NET Core? And each platform is composed of a runtime environment (CLR, Mono, CoreCLR) together with a base set of libraries (like the BCL) and with supporting software for booting the runtime environment and interfacing with the OS? In that case since .NET Framework 2.0 - 4.6 had all of these it is a specific platform. But to develop store apps for example, a new runtime was built with a new base set of libraries and new supporting stuff and the same goes on for all those verticals? – user1620696 Feb 16 '16 at 13:24
  • I intentionally avoided posting that diagram, it does not really help imo. The bottom layer does matter most, .NET must run on top of it and that does affect what it looks like and what it can do. The changes in the CLR to support store apps (WinRT) are actually pretty modest. What really changed is the OS interface, it is as different as, say, OSX is different from iOS. Microsoft marketing strategies are getting in the way if seeing that if you don't know the platform well enough. – Hans Passant Feb 16 '16 at 13:34
  • In that case the main difference across platforms is the library which is included by default? So, .NET Framework has the base class library, while the store apps has another set of libraries included by default? Apart from that, there are also differences on the CLR I believe. And the idea is to make the framework be optmized for the different environments on which it will run (e.g. a browser, a phone, or a full desktop)? – user1620696 Feb 16 '16 at 15:21
  • The reference assemblies you use to build your project are what matters most. There are lots and lots of different sets, have a look-see at the content of your c:\program files (x86)\reference assemblies directory for example. – Hans Passant Feb 16 '16 at 15:25
  • I saw the directory. Those are the assemblies we use in development in Visual Studio right? But the assemblies used to really run the application are the ones available in the GAC of the environment on which we deploy the application right? – user1620696 Feb 16 '16 at 16:20
  • Perhaps. More implementation details, well hidden, a CoreCLR or Silverlight or Store or UWP app does not use the GAC. The latter two don't use a framework at all, it is built into the package by .NET Native. – Hans Passant Feb 16 '16 at 16:34
5

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

Juergen Gutsch
  • 1,774
  • 2
  • 17
  • 28
5

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

Pierre Murasso
  • 591
  • 7
  • 14