What is .NET? A handy guide to impeccable vision and more
Chances are that at some point you might have used a Microsoft Windows PC. If that’s the case, then you’ve probably installed some applications and, during the installation process, the wizard stated that Microsoft .NET (pronounced “dotnet”) is required to run said apps. So what is it then? Do you need it? And what’s that about impeccable vision? In this article, I will try to answer all these questions and even maybe some more.
Table of contents
History of .NET
Before we dive into its history, let’s answer the titular question - what is .NET? These days, it seems to be an umbrella term encompassing the .NET runtime, also known as CLR, which is the execution environment for .NET applications, as well as the framework - a standard library of functions and types which allows the developer to interact with various resources, like network, ports, file system, memory, OS services, and many, many more.
You may also like:
Dotnet Version 1.0
Released by Microsoft in April 2002 (see lifecycle start date here), the very first official release of .NET allowed for ASP.NET server-side applications and was supposed to supersede the “classic” ASP. The latter was a scripting framework used to execute VBScript, a derivative of Visual Basic programming language, while the former used compiled assemblies written in languages like C# and Visual Basic .NET (which, as a side note, later dropped the .NET suffix to both help prevent and cause confusion).
Dotnet Version 2.0
The second major release of .NET saw the light of day in February 2006. Some of the most notable changes were: support for 64-bit computing, .NET Micro Framework, CLR 2.0 and more. One of the notable changes to the CLR was the addition of generics, which allows the writing of more concise code by eliminating repetitions.
Dotnet Version 3.0
Released in November, the same year as version 2.0, version 3.0 brought a brand new programming model for Windows desktop applications - WPF (Windows Presentation Foundation), as well as a platform for remote procedure calls - WCF (Windows Communication Foundation). Moreover, WF (Windows Workflow Foundation) and CardSpace were added, with the former being a framework for building business logic workflows with an optional visual designer, and the latter being a discontinued identity management system.
Dotnet Version 3.5
While we’ve skipped .NET 1.1 and a range of Service Pack releases, version 3.5, released November 2007, brought one of the most widely used features to date, LINQ (Language INtegrated Query), which is a mechanism for manipulating collections of data, both in-memory and, via the use of various query providers, in e.g. SQL databases. Here’s a non-trivial example of two types of LINQ syntax used to create all-to-all pairs from a collection of numbers:
var range = Enumerable.Range(0, 10);
// query comprehension syntax
var pairs1 = from x in range
from y in range
select new { x, y };
foreach (var pair in pairs1)
{
Console.WriteLine($"x: {pair.x}, y: {pair.y}");
}
// functional/fluent syntax
var pairs2 = range.SelectMany(c => range, (x, y) => new { x, y });
foreach (var pair in pairs2)
{
Console.WriteLine($"x: {pair.x}, y: {pair.y}");
}LINQ relied heavily on another new feature, Expression Trees, which makes it easy to traverse and build coded query logic in runtime. An example is worth a thousand words, so I would like to present a strong contender for the most convoluted code, which checks whether a square of a number is greater than that number doubled:
var parameter = Expression.Parameter(typeof(double));
var two = Expression.Constant(2.0, typeof(double));
var squared = Expression.Power(parameter, two);
var doubled = Expression.Multiply(parameter, two);
var isGreater = Expression.GreaterThan(squared, doubled);
var lambda = Expression.Lambda<Func<double, bool>>(isGreater, parameter);
var function = lambda.Compile();
Console.WriteLine("x^2 > 2x");
Console.WriteLine($"x = 1: {function(1)}");
Console.WriteLine($"x = 2: {function(2)}");
Console.WriteLine($"x = 3: {function(3)}");
// x^2 > 2x
// x = 1: False
// x = 2: False
// x = 3: TrueDotnet Version 4
Microsoft released version 4 of .NET in March 2010 and it came accompanied by CLR, updated from v2 straight to v4, because it is a well-known fact that people from Redmont are the best at assigning version numbers. Among other features, in this release we had dynamic binding, a new thing in CLR which is not often seen in production code, but it allows you to change the runtime type of a variable.
As a dedicated fan of strong, static typing, I’d like to discourage the usage of this feature, unless you have an excellent excuse to do otherwise. Another new thing was the Task Parallel Library, which enables a new model of asynchronous programming for .NET developers via a simple API. While it was cool to begin with, it has since reached a level of coolness that was orders of magnitude greater with the advent of…
Dotnet Version 4.5
…which debuted in October 2012, bringing such joy as C# 5 with async/await keywords, which greatly simplified the use of asynchronous Tasks introduced in the previous release, as well as some general performance improvements. At this point it also became apparent that the old compiler’s codebase had become harder to work with, as only two new features found their way to the language, compared to four or five in previous releases. This was to change with the next big version of .NET.
Dotnet Versions 4.5.1 and 4.5.2
In 2014, we had two point releases which brought developers improvements in debugging experience, as well as better support for high DPI scenarios in WPF and Windows Forms.
.NET 2015
Dubbed as such in the official docs, this consists of two distinct parts: .NET Framework 4.6 and .NET Core 1.0. The latter is a brand new flavor of .NET made by Microsoft, which runs on Windows, Linux and MacOS. The core idea behind it is to have a framework which can support side-by-side and bundled deployments, and therefore allow for greater flexibility and more frequent updates because you don’t need to update the machine-wide framework and cross your fingers that nothing breaks, but instead you can create one application against one version and then create another with a newer one and take advantage of some fancy features and improvements, and no conflicts whatsoever will arise. Another new thing that came out was RyuJIT, a new JIT compiler with full 64-bit architecture support.
Speaking of compilers, Roslyn, the new Dotnet Compiler Platform also saw its official release and came with a set of APIs which enable writing of so called Roslyn analyzers - packages which can be used for static code analysis beyond what comes bundled by default. An example of such a custom analyzer is CLR Heap Allocation Analyzer, a tool which provides hints that help reduce the number of (often implicit) allocations in the code. At this point, it is worth mentioning that all things .NET Core are completely free and open source.
.NET today
Fast forward to early 2019, where we have .NET Framework 4.7.2 and .NET Core 2.2 with 3.0 being in public preview. We’ve seen Windows Forms, Windows Presentation Foundation and XAML go open source though, sadly, not cross-platform for the first two (Windows still refers to “Microsoft Windows”, not application windows, although you can still use Windows Forms on Mono). We can now run .NET apps on Mono in the browser using WebAssembly. It is possible to load most NuGet packages targeting whatever framework into your application, provided they use APIs defined in .NET Standard (that is, not something platform-specific, but the common core). C# 7.3 (and 8 in preview) provides new syntax and features to improve the development experience, as well as allows writing very high-performing code using Span APIs for direct memory access and Pipelines for fast I/O, and more. It’s been a long way since the first releases and, fortunately, there’s no end in sight.
Mono, Core, Standard, or Framework?
You might think, “Wait a minute, that’s a lot of names. What’s Standard? And Mono? Explain yourself!”, and I will happily oblige. Let me briefly introduce the components of the Dotnet world.
.NET Framework
The one, the original, Microsoft .NET Framework is a set of libraries and tools you can use to create and run an application. It works on Windows, has its own Framework Class Library and uses CLR for the actual code execution (more on that later). Its components allow writing web (server-side) and desktop applications by means of ASP.NET and WPF/WinForms respectively.
.NET Core
Framework’s younger sibling, .NET Core does pretty much the same thing, but on MacOS and Linux as well as Windows. It also supports ARM architecture, making it a viable choice for IoT scenarios, even more so in version 3.0 which will provide APIs for GPIO pins. Its base class library is CoreFX, and the runtime is CoreCLR. You can use it to write Windows desktop applications (also in 3.0 using either WPF or WinForms - sadly those are not cross-platform), web (server-side) using ASP.NET Core, and also, should we take community projects into consideration, cross-platform desktop applications using AvaloniaUI. It’s a fast-moving framework supporting side-by-side deployments if you need them, but it also allows you to bundle the framework with your application, and therefore eliminating the need for installing any dependencies whatsoever.
ASP.NET Core
Caution, opinions ahead! If creating web applications is your thing, Microsoft (or rather, the .NET Foundation) has your back. I know that it was mentioned before, but there’s just too much goodness to just gloss over it. The main advantage for many is that you can host your web services on Linux servers, not just expensive Windows ones.
User authentication and authorization? It’s there and it supports external identity providers like Facebook, Twitter, Google, etc. Real-time applications support? Look up “ASP.NET Core SignalR”. Privacy? There are helpers for cookie policy notifications and GDPR terms in general, as mandated by the EU, so privacy is (mostly) taken care of for you. Writing client-side logic in C#? In deep preview, but it’s here. Want to make your web application into desktop software? Electron.NET makes it possible. Development of web services and cloud-based software is a breeze with ASP.NET Core!
Mono and Xamarin
Mono does what .NET Core and .NET Framework do, except its focus is on portability. It started as an implementation of .NET that could run on Linux, but gained much traction over time, and now you can use it to create cross-platform mobile apps using Xamarin, as well as games with MonoGame, where its portability is the most apparent: you can run your (Mono) game on Windows, MacOS, Linux, PS4, PS Vita, XBox One/360, Android, and iOS.
Unity3D
MonoGame is not your only option when it comes to games. There’s also Unity3D, another, well-established game engine based on Mono, albeit heavily modified. Unity games will run wherever MonoGame ones do, but additionally on numerous other platforms.
CLR and IL
The low level stuff. CLR, the Common Language Runtime, is the actual piece of software which executes .NET applications. It provides memory management, garbage collection, JIT compilation, and security mechanisms. But what’s that IL thing? Intermediate Language (formerly CIL - Common Intermediate Language, formerly MSIL - Microsoft Intermediate Language), is the assembly of the .NET virtual machine. Applications written in C#, VB, F#, and other .NET languages are not compiled directly to machine code, but instead IL assemblies are created, and those in turn are executed in the CLR by means of JIT compilation, which translates IL to appropriate CPU instructions on the fly, as the code executes.
Programming directly in IL is possible but ill-advised. It’s not really a language for humans to write code in, so unless you’re using it purely for mental gymnastics, give us a call and we will send help.
CoreRT
With all that said, one might think “But do we need this whole JIT thing? Can we not make a native assembly in the first place?”. Well, sure. Lo and behold: CoreRT, a .NET Core runtime, except optimized for AOT compilation. It is in a very early stage of development, and is certainly not production-ready, but it is worth keeping an eye on what becomes of it. Code compiled ahead-of-time should start and run more quickly and can possibly be bundled into a single binary.
.NET Standard
This is another .NET thing which seems to confuse people, while in reality it is quite simple. .NET Standard is nothing more than a contract which defines a list of APIs that you would need to implement to call yourself compliant with a particular version of the standard. For example, if you create a class library against .NET Standard 1.4, then it is guaranteed that it will work with a framework which implements the standard 1.4 or higher (be it Mono, Core, Framework, UWP, or any other), because the APIs you might be using must be there. But you might ask - didn’t we have something similar already? The Portable Class Libraries? That’s correct, those were a thing, but worked on a different principle. API sets available in PCLs were an intersection of all target platforms, not a versioned contract. They were also tightly bound to Microsoft’s platforms, whereas .NET Standard is platform-agnostic.
Dotnet languages
It was mentioned that IL is .NET’s lingua franca,but nobody in their right mind would write production code in it. Instead, there’s a wide array of high-level languages you can use, and I would like to introduce the most notable ones.
C
C# is a general-purpose, object-oriented, strongly and statically typed programming language with support for generics and elements of functional programming. It belongs to the family of C-like languages and is inspired by a number of other modern ones, like F#, Python, and Java.
F
F# is a functional-first, object-oriented, strongly and statically typed programming language with a strict type inference and concise, powerful syntax. It takes, among others, after C#, Haskell, Scala and Python. While not as popular as C#, it has found its niche in scientific computations, and on the web (who would have thought?) as one of JavaScript alternatives via the use of Fable.
VB.NET
Visual Basic .NET is similar to C# paradigm-wise, although it’s based on Visual Basic, not C, and therefore can be immediately differentiated by its syntax. Until recently, it had a feature parity with C#, but has fallen behind the faster developing language. It also isn’t fully supported on .NET Core, which makes one think that it’s past its prime. Regardless, it still remains a popular choice because the idea behind Visual Basic, that it is a language that anyone can learn and use, still holds true. Although it seems to be receiving less and less love, so who knows what will become of it?
…and many more
Would you like to run Python on .NET? If so, then there’s IronPython. Maybe C++ is more of your thing? In that case C++/CLI would be your go-to language. Or perhaps you need to do some shell scripting but feel comfortable with .NET? PowerShell is what you can use. These are the most prominent of the less notable languages, and there are really many more, except not so widely used, if at all. Pascal developers would like Oxygene, COBOL devs, Visual COBOL. Even Java developers have a CLR-compliant version of their language - J#. You can pick and choose!
Summary ON .NET
From humble beginnings, to a platform enabling the creation of any type of application, .NET has gone far not only in technological sense, but also philosophically. It started as a closed-source, slow-mowing monolith under Microsoft’s iron grip and ended up as a modular, open source framework with frequent updates and LTS releases for those who require stability they’ve grown used to over the time spent programming against the “old” framework. If you haven’t, give .NET a try, it’s really fun to use, there’s always something more to be learnt about it, and there’s always a community which will lend a helping hand over the web, be it StackOverflow, MSDN, or Github.
Share this article:
