.NET is probably one of the more muddled and mismanaged brands in the history of Microsoft. If you go to microsoft.com it will tell you that ".NET is the Microsoft Web services strategy to connect information, people, systems, and devices through software," but this isn't what most people are thinking of when they say, ".NET." What is commonly referred to as .NET is programming with the .NET Framework. This is what I am going to cover in this article. If you are looking for marketing speak then please refer to www.microsoft.com/net.
At the heart of .NET is the Common Language Runtime, commonly referred to as the CLR. The CLR is made up of a number of different parts, which I will be covering here piece by piece (if you didn't want a technical article then you should've followed the marketing link).
One of the most important facets of the .NET Framework is language independence. You can write .NET applications using any number of different programming languages. The most popular languages tend to be C# and VB.NET, but many other languages now have .NET versions including Python, COBOL, and more. You can see a list of many of the languages you can use with .NET over at dotnetpowered.com/languages.aspx.
Language independence is attained through the use of an intermediate language (IL). What this means is that instead of code being compiled in actual machine code (code that the CPU would run), it is instead compiled into a high-level generic language. This means that whatever language you write your code in, when you compile it with .NET it will become IL. Since all languages eventually get translated into the intermediate language, the runtime only has to worry about understanding and working with the intermediate language instead of the plethora of languages that you could actually use to write code.
If your mantra is, "Why do something now you can put off till tomorrow?" then you have something in common with the CLR. When you compile your code and it is translated to the intermediate language it is then simply stored in an assembly. When that assembly is used the CLR picks up that code and compiles it on-the-fly for the specific machine that is running the code. This means the runtime could compile the code differently based on what CPU or operating system the application is being run on. However, at this point the CLR doesn't compile everything in the assembly; it only compiles the individual method that is being invoked. This kind of on-the-fly compilation, referred to as jitting, only happens once per method call. The next time a method is called, no compilation occurs because the CLR has already compiled that code.
One of the constant assailants on productivity in unmanaged programming platforms is manually managing memory. Having to deal with memory management is also one of the largest sources for bugs and security holes in many applications. .NET removes the hassle of manually managing memory through the use of the aptly named garbage collector. Instead of the developer needing to remove objects from memory, the garbage collector looks at the current objects in memory and then decides which ones aren't needed anymore. For some developers this will be a tough pill to swallow; if you are used to managing memory then turning it over to an automated process can be somewhat troubling. This is when you have to take a step back, stop worrying, and embrace the runtime. There are bigger problems to solve (namely the business problems that are probably the real goal).
The .NET runtime is actually based on a standard developed by Microsoft called the CLI or Common Language Infrastructure, portions of which have been submitted to Ecma as an international standard. Because the CLR is based on an open standard, there have been a number of alternative CLR implementations, most notably Rotor and Mono. Rotor was a project from Microsoft Research, is a version of the CLR that will run on Mac OS, and is shared source. Mono is an independent open source implementation of the CLR that runs on various Linux distributions. While "Write once, run away" is not always realistic with .NET, there are some options available when it comes to other platforms. (Some code can be moved without issue, but most will require some tweaking, as different implementation includes different functionality.)
While the runtime is definitely the most important part of .NET, you can't do too much with it by itself. This is where the Base Class Library (or BCL) comes in. The BCL includes a lot of the plumbing of .NET, including the system types, IO, and functions for working with text. In addition to the BCL, there is the Framework Class Library (FCL). The FCL is an extended library that makes working with the .NET Framework practical and includes the following major pieces:
Most current applications involve working with databases, normally more than one. ADO.NET is the data access component of the .NET Framework and includes built-in providers for SQL Server, ODBC, OLEDB, as well as Oracle.
Windows forms are the .NET Framework method for building desktop-based applications. Windows Forms are simply a managed wrapper over the native Windows API, this means that you can write code for one version of Windows and it will run on other versions without issue all the way back to Windows 98 SE.
Windows forms applications do require the .NET Framework to run, which means that anyone who downloads your application, or any computer it is installed on, will need to also have the .NET Framework. The framework can be easily installed through Windows Update, and is completely free, but the download size can be troublesome for people with a slower connection.
ASP.NET is the part of the .NET Framework dedicated to building web applications. Using ASP.NET you can build everything from a small starter website to enterprise-level web applications. ASP.NET allows you to write web applications without the need for a scripting language, everything can be written in your .NET language of choice.
Since ASP.NET applications are simply rendering HTML for the browser, there is no requirement for the .NET Framework on the client. Chances are you have used a number of sites that have been written in ASP.NET and you might not even have known it.
With ASP.NET Web Services Microsoft has created a number of time-saving features to make it easy to quickly write and expose web services from your application. Just like the rest of .NET, ASP.NET Web Services can be written in any .NET language. Through the use of the Web Services Extensions (free download from Microsoft), you can also add support for the new and ever-growing list of WS-* specifications to your ASP.NET Web Services.
One of the benefits of the .NET Framework is the great tools that are available to the .NET developer. Visual Studio has long been considered one of the premier IDEs on the market and does a lot to increase developer productivity when working with the framework. There are also a large number of open source tools available for .NET, including many that mimic the tools available on other platforms. Some of these include nUnit for unit testing, nAnt for building projects, nCover for testing code coverage, nHibernate for object persistence, and much more.
This November, Microsoft will launch .NET 2.0, the first major revision of the .NET Framework. With this revision .NET will grow to include a large amount of new functionality, not just in ASP.NET, Windows Forms and the base library, but also with the addition of support for new language features like generics to the runtime. Microsoft has shown its commitment to this platform and will continue to build upon .NET for years to come. (There is already some public information available on the next version of .NET, which is code-named Orcas.)
Author's Note: Thanks to Dave Donaldson, Jayme Davis, and Jim Holmes for reviewing and providing valuable feedback on this article.
James Avery has been programming with Microsoft technologies for the last 7 years and has been working with .NET since the second beta release.
Return to ONDotNet
Copyright © 2017 O'Reilly Media, Inc.