On the way to “.NET One”

After 15 years of .NET Framework and strategy called “Write Once Run Everywhere”, we obviously need to provide some clarification. You will probably not believe me, but we had 14 different versions of .NET. On the way to unify everything in the single story (I call it .NET One) Microsoft will make number 15. This sounds strange, but it might rely help.

What is .NET Core?

This is the name of the Basic Class Library (BCL)  that should be used (in the near future; today is 2015) by various platforms, APIs and toolsets. For example Universal Apps and ASP.NET should use this framework and let run your application on any Windows (10+), Linux or MacOS operative system.

                                                        Architecture as shown at //build/ 2011

                                                      Architecture of .NET Core

Currently, it refers to the set of .NET APIs (i.e.: System.Collections.Generic.List`1 etc.).

Right now, only ASP.NET has dependency to .NET Core. Universal Windows Platform (UWP) has not yet been hooked up into this strategy. As you see on picture above There is no UWP (it is Windows Store App Model, which has strategically evaluated to UWP ). In another words today (year 2015) so you cannot consume .NET Core in your Universal Windows App, yet, But you will be able to that in the future = by RTM of Windows 10.

Universal Windows Platform

This is the name of application platform on Windows 10 family. One Universal App (the app which runs on top of UWP) can run on any Phone, Tablet, Desktop, Xbox One, HoloLens and IoT device that is running Windows 10. Right now such app cannot run on Linux and MacOS like .NET Mono does. But in the future UWP will consume .NET and should be able to run on other operative systems. Because Universal App has also dependencies to bunch of Windows libraries like WinRT and System32, I personally expect organizational complexity, which might lead to apps, which do not run on Linux and MacOS. I hope I’m wrong.

As I already mentioned, UWP also references a subset of WinRT. To get a feeling of amount of WinRT types which are used by UWP open following XML file”":

c:\program files (x86)\windows kits\10\platforms\uap\10.0.10069.0\platform.xml. This file contains explicit references to WinRT libraries: FoundationContract, UniversalApiContract and WwanContract.

<?xml version="1.0" encoding="utf-8"?>

<ApplicationPlatform name="UAP"
friendlyName="Windows 10 Tech Preview" version="10.0.10069.0"> 

   <MinimumVisualStudioVersion>14.0.22213.01</MinimumVisualStudioVersion>

   <ContainedApiContracts> 

      <ApiContract name="Windows.Foundation.FoundationContract"      
                   version="1.0.0.0" /> 

      <ApiContract name="Windows.Foundation.UniversalApiContract"
                   version="1.0.0.0" /> 

      <ApiContract name="Windows.Networking.Connectivity.WwanContract"
                   version="1.0.0.0" />

   </ContainedApiContracts> 

</ApplicationPlatform> 

Every reference can be found in list of all WinRT contracts c:\program files (x86)\windows kits\10\references.
Following pictures show types which are used in Foundation contracts.

Following types are referenced from UniversalApiContract:

And, finally types from WwanContract:

One more thing is important here, which brings more complexity in “unification story”. Universal Apps compile into .NET native. .NET Core don’t according to the picture from //build/ 2015! Interestingly in the architecture picture of .NET Core above there is an adoption layer to .NET native from .NET Core.  As you see both worlds have significant advantages, which I truly like.

WinRT (Windows Runtime)

This is not the platform. PERIOD. It is the name of a technology or runtime (C-runtime that underpins Windows APIs going forward. It is built on top of COM and Win32. This technology is mainly build for AppContainer-based apps (“Store-Apps”, “Phone 8.1” and also “UWP”) and within Phone Silverlight apps. This runtime can also be consumed by Desktop Apps as I described here. See also this Scott’s blog post.
Due “projections” architecture of WinRT JavaScript, C++ and .NET can “consume” WinRT.

Original architecture as shown at //build/ 2011

Note that C++ XAML apps and JavaScript apps will naturally not be able to use .NETCore. This is naturally not possible, because .NETCore is a set of .NET libraries. It is physically different and it cannot be used, without of some kind of “back-projection” (oposite to WinRT projections, which is currently not on the roadmap.

It is important to now that WinRT APIs is technology on top of COM. That means that at low level every language have to call CoCreateInstance (or rather RoActivateInstance), and then QueryInterface, and so on. Even in C++ we still access WinRT through a projection layer. That means evenC++ command “new Windows.UI.Xaml.Controls.Button()” will be turned into a complex set of COM operations.
Actually, there is a low-level library for C++ called “WRL” which bypasses the projection layer, and has you accessing the WinRT APIs directly. I never wanted to know that  

To recap WinRT is not native to any language. Most developers think that it is native to C++.

Recap

Most developers were disappointed with WinRT. We stepped back from many, many languages to only 3 projected languages. We were catapulted back to COM from the nice world of .NET. The reason for this was performance and battery power. Fortunately we  tuned performance of .NET by providing .NET native and we will be able to optimized battery consumption by implementing the set of core libraries, which have no dependency to power killer machine Win32.
One may ask, why didn’t we do this before? In fact we all are under the low of evolution. We were not able to do .NET native because of many reasons. Many developers think that DLL-hell expression has roots in GAC and Co. This is not true. This expression was introduced first time in System-Journal long before .NET time. Windows was built at these days (1990-es) to save RAM and to increase performance by reusing already loaded DLL-s. This helped a lot. But the number of applications increased dramatically and this became the HELL in replacing of DLL-s which was used by other applications.
Now, have have “cheap” memory and we do not need to reuse DLLs. that intensively way. That means every application will have its own copy of DLL. This is exactly opposite way in comparison to 1990-es. But remember .NET native will remove everything application does not need to get smaller footprint. And Windows10 will also reuse same versions of DLL.
But sometimes evolution behaves not very optimized way in nature, but obviously also in technology. In other words, some steps were not necessary necessary. I believe that we could get here with fewer than 14 versions of .NET framework. I also believe that stepping back to COM was probably not the best way and definitely not expectation of community. 

Following table shows a simplified summary about platforms, which .NET developer has to target today and in the near future:

At the end we have to be aware of a fact, that current story is NOT about Universal Apps. It is about Universal Windows Apps. That means we seem not to be far away from .NET One for every platform and every device. But right now it is still my (or our) wish or even better to say “Expectation”.

Damir