.NET Framework

The .NET Framework, 

The name “.NET Framework” itself is a bit of a misnomer. A?framework?(in programming terms) is really a collection of Application Programming Interfaces (APIs) and a shared library of code that developers can call when developing applications, so that they don’t have to write the code from scratch. In the .NET Framework, that library of shared code is named the Framework Class Library (FCL). The bits of code in the shared library can perform all kinds of different functions. Say, for example, a developer needed their application to be able to ping another IP address on the network. Instead of writing that code themselves, and then writing all the little bits and pieces that have to interpret what the ping results mean, they can use code from the library that performs that function.

And that’s just one tiny example. The .NET Framework contains tens of thousands of pieces of shared code. This shared code makes the lives of developers much easier because they don’t have to reinvent the wheel every time their applications need to perform some common function. Instead, they can focus on the code that’s unique to their applications and the user interface that ties it all together. Using a framework of shared code like this also helps provide some standards between applications. Other developers can make sense of what a program is doing more easily and users of the applications can count on things like Open and Save As dialog boxes working the same in different applications.

So, why is the name a misnomer?

Because in addition to serving as a framework of shared code, .NET also provides a?runtime environment?for applications. A runtime environment provides a virtual machine-like sandbox in which applications run. Many development platforms provide the same kind of thing. Java and Ruby on Rails, for example, both provide their own runtime environments. In the .NET world, the runtime environment is named the Common Language Runtime (CLR). When a user runs an application, the code for that application is actually compiled into machine code at runtime and then executed. CLR also provides some other services, such as managing memory and processor threads, handling program exceptions, and managing security. The runtime environment is really a way of abstracting the application?from the actual hardware on which the application runs.

There are several advantages to having applications run inside a runtime environment. The biggest is portability. Developers can write their code using any of a number of supporting languages, including such favorites as C#, C++, F#, Visual Basic, and a few dozen others. That code can then be run on any hardware on which .NET is supported. While the platform was ostensibly designed to support hardware other than Windows-based PCs, however, its proprietary nature led to it mostly being used for Windows applications.        

Microsoft has created other implementations of .NET to help resolve this. Mono is a free and open-source project designed to provide compatibility between?.NET applications and other platforms, especially Linux. The .NET Core implementation is also free and open-source framework designed to bring lightweight, modular apps to multiple platforms. .NET Core is intended to bring support to Mac OS X, Linux, and Windows (including support for Universal Windows Platform apps)

As you can imagine, a framework like .NET can be a real boon on the development side of things. It allows developers to write code using their preferred language and be assured that code can run wherever the framework is supported. Users benefit from consistent applications and also the fact that many apps might not be developed at all if the developers didn’t have access to the framework.

How Does .NET Get on My System?

The .NET Framework has a somewhat tortuous history, and has seen a number of versions over the years. Typically, the newest version of .NET available would be included in the release of each version of Windows. The versions were intended to be backwards-compatible (so an application written for version 2 could run if version 3 was installed), but that didn’t work out so well. Not all applications worked with the newer versions. On systems running Windows XP and Vista, especially, you’d often see multiple?different versions of .NET installed on a PC.

There were essentially three ways that any particular version of the .NET Framework would get installed:

Your version of?Windows might have it included in the default installation.
An application that required a particular version might install it during its own installation.
Some applications would even send you to a separate download site to grab and install a particular version of the .NET Framework.

Fortunately, things are smoother in modern versions of Windows. Sometime during the Windows Vista days, two important things happened. First, .NET Framework 3.5 was released. That version was reworked to include components from versions 2 and 3. Apps that required earlier versions would now work if you just had version 3.5 installed. Secondly,?upgrades to the .NET Framework finally started being delivered through Windows Update..