Programming Windows: What is .NET? (Premium)

Developers curious about the future of the Microsoft developer stack filed into PDC 2000 in Orlando to learn more about .NET in July 2000. It was an information-packed event, with lots of new technology and terminology. But what most developers were looking for was some clarity after the vague messaging that Microsoft had provided at Forum 2000. Exactly what was .NET, really? And how did the nuts-and-bolts implementation of this technology map to the vague promo videos that Microsoft had provided a month earlier?

According to Microsoft’s day one documentation, .NET is “Microsoft’s strategy for delivering software as a service.” It would consist of three main components, the Microsoft .NET platform, various Microsoft .NET products and services, and third-party .NET services. Here, of course, we are concerned with the first of those three components. Which leads us naturally to the next question: what is the .NET platform?

Here, again, I will turn to the original documentation, which notes somewhat vaguely that it includes the .NET infrastructure needed to operate a new generation of services, the tools needed to build a new generation of services, a new .NET user experience to “enable rich clients,” .NET building block services, and .NET device software to enable a new generation of smart Internet devices.

That’s a lot of stuff. And it is interesting to note, some 20 years later, which parts of that Microsoft delivered, immediately or over time, and which parts it did not. For example, the .NET user experience—which was heavily evident in the Forum 2000 and PDC 2000 keynotes in Spring 2000, never came together in a meaningful way. It eventually found a home at MSN, which evolved over time from Internet connectivity software, similar to AOL, to an online content hub, and then a set of tools that enhanced Windows for the Internet. We also saw leaked imagery of Windows Blackcomb that featured this UI, but Blackcomb was later canceled, and its replacement project, Longhorn, went in a different direction.

But the core piece of the .NET infrastructure, the underlying plumbing that made .NET possible in the first place, the .NET Framework, was available immediately, at least in beta form. The developer attendees of PDC 2000 received the first external bits on CD so that they could see where Microsoft was heading.

Historical aside: Given the pervasive nature of broadband connectivity today, it is perhaps not obvious that the Internet of 2000 was quite different and consisted mostly of slow dial-up access. Those developers who didn’t attend PDC 2000 could get the .NET Framework SDK from Microsoft as a single 110 MB download or as a dial-up friendly 11-part download. But the software giant also offered to mail developers the code on CD.

So, what’s the .NET Framework?

According to the original documentation, the. NET Framework is an environment for building, deploying, and running web services and other applications. And I find that interesting: that original description very much emphasizes web services over, say, Windows applications. Not because the .NET Framework would not be used later to create a more modern foundation for desktop applications or other client apps. But because those web services would be delivered by Windows servers and consumed largely by Windows-based clients running on PCs and new mobile devices. And those Windows-based clients would, over time, acquire more .NET features, including a bundled version of the .NET Framework and its runtime (discussed below) and that .NET user experience.

Like .NET itself, the .NET Framework consisted of three main parts: a runtime enabling .NET code to execute on Windows servers and clients, a set of object-oriented classes that developers could access in their language of choice via the .NET Framework SDK, and ASP.NET, the successor to Microsoft’s web server-based Active Server Pages (ASP) which was previously codenamed ASP+.

The original beta version of the .NET Framework could be installed on Windows 2000 (client or server), Windows 95/98/ME, or Windows NT (client or server). Microsoft was also working on a .NET Compact Framework for Windows CE “and other embedded operating systems” that would target “cell phones and enhanced televisions” and “devices that do not require an operating system.” It would offer a subset of the capabilities of the full .NET Framework, but the details were initially vague.

The .NET Framework was designed from the start to be language agnostic. That is, rather than requiring a different version of the framework and its runtime for each supported language, as had been the case with pre-.NET languages like Visual Basic and C++, any language could support the .NET Framework, and developers could mix and match languages as desired, with cross-language inheritance and debugging. At launch, Microsoft said that it would support .NET Framework development in C++, Visual Basic.NET, JScript, and “Microsoft’s latest” language, C# (“see sharp). (Technically, C# was Microsoft’s first language, in the sense that it was the first full-featured programming language that it developed in-house.) Third parties would quickly support .NET in dozens of other languages, including COBOL, Eiffel, Perl, Python, Smalltalk, and others.

The .NET runtime was known as the Common Language Runtime, or CLR. The CLR was “the execution engine of the .NET Framework application,” as Microsoft put it at the time, and it offered several modern services to those applications that really set it apart from previous Microsoft runtimes. Most notably, it provided code loading and execution management, memory management (garbage collection, plus memory isolation), type safety verification, enforced code security access, and exception handling. It could also handle interoperability between so-called .NET managed code and unmanaged code in dynamic link libraries (DLLs) and COM objects.

.NET applications and services were not typically compiled directly into executable files, or EXEs. Instead, they were compiled into the Microsoft Intermediate Language (MSIL), a platform-agnostic instruction set that was converted to machine code when executed. So .NET wasn’t interpreted, like early Visual Basic languages, but worked similarly to Java.

From the perspective of a developer looking at source code, the .NET Framework offered dramatic improvements over legacy developer environments. Standing in sharp contrast to the flat, C-based Windows API, it was object-oriented, well-designed, and consistent, with a clear hierarchy of classes. It offered a much simpler approach to COM development. And developers could target .NET using Visual Studio.NET (formerly Visual Studio 7.0), which promised to offer a single IDE for all supported languages and new extensibility features; an alpha version of the product was distributed at PDC 2000.

But those interested in Windows application development would need to wait for more information about how or whether the promised .NET “rich Internet user experiences” would translate to the desktop. The alpha version of Visual Studio.NET surely provided some hints, including the seismic changes that would come to Visual Basic in this release. But it wouldn’t be long before Windows developers learned of a new forms-based Windows application environment that would work nearly identically with both Visual Basic.NET and C#.