It has been quite a while since we developers have had something to get this excited about. Microsoft has released some exciting technology for developers recently�COM+, the WebStore, Microsoft SQL Server 2000's native XML support�but these products have been, for the most part, infrastructure hand-me-downs. .NET is about to change all that. Although Microsoft .NET will influence nearly every aspect of Microsoft's product line�in fact we are already starting to see the impact with the recent release of the .NET Enterprise Servers�it's really all about making developers more productive. It's about time.

Roughly a year has passed since Microsoft announced the .NET strategy at the Forum 2000 event last May and it has generated a tremendous amount of excitement.  If you ask a handful of your colleagues what .NET is, you are sure to get a variety of answers. Some people might mention aspects such as software as a service, Web Services and XML everywhere, and �xcopy� deployment. Others might mention the Common Language Runtime (CLR), managed code, and the Microsoft Intermediate Language (MSIL). Though I doubt that any two people will list all the same .NET features, one feature I bet nearly everyone will include is Microsoft's new language, C#.

Because Microsoft designed C# with .NET in mind from the very beginning, the best way to learn about .NET is to learn C#. The best way to learn C# is to get a copy of Tom Archer's new book, Inside C#. This book offers an in-depth look at the C# architecture and programming elements. You can check out the table of contents and even read Chapter 7, �Properties, Arrays, and Indexers.�

In this article, I aim to provide an introduction to .NET and discuss some of the ways that it will make you rethink (in a good way) how you approach software development. Because Microsoft built C# from the ground up to be a first-class .NET language, the best place to start is with a programmer's overview of .NET. From there I will move on to a brief discussion of the C# language itself; I'll conclude with a discussion of the effect that a completely object-oriented .NET language will have on the way we approach complex projects.

The .NET Vision
Microsoft .NET is a huge initiative from Microsoft, with many interrelated components. Fortunately, you can break it down into four big pieces:

Servers 
As I mentioned above, these are the first shipping products that support the .NET vision.  The .NET Enterprise Servers fall into two categories: First are the core servers, such as Microsoft Windows 2000, Microsoft Exchange 2000, and Microsoft SQL 2000, which provide the essential platform services. Second are the utility-style servers, such as Microsoft BizTalk Server 2000 and Microsoft Host Integration Server 2000, which are designed around integrating business processes across heterogeneous systems.

Building Block Services 
When I talk to people about the components of .NET, the building block service always generates the most confusion. Everyone looks at the building block service strictly in terms of Passport, but that site is just the beginning. Think of building block services as any sort-utility function that is shared across applications and can be delivered over the Internet. Building block services are the distributed counterparts of the core services that Microsoft Windows pioneered, such as memory management and printer drivers. Prior to the release of Microsoft Windows, each application had to have its own printing mechanism and memory-management process. To make matters worse, in most cases the user had to manually configure these settings. For example, if I wanted to control the output of my snazzy Epson printer, I had to research the esoteric escape codes and then key them into each application. Configuring memory management was even worse! In a .NET world, building block services will free us from having to write basic plumbing such authentication and payment processing, letting us focus on the real value of our services. Better yet, third parties will have an incentive to provide these building block services, just as VBXs in Microsoft Visual Basic created a new industry.

Devices
.NET is about moving from a PC-centric world in which all your data resides on a single PC (or a LAN connection to the PC) to a world in which your data and preferences follow you as you interact with various devices. This involves more than just the network infrastructure that ensures that your data is available any time on any device (although that is no simple feat). This is about designing user interfaces that degrade gracefully and designing storage and processor requirements that scale appropriately as we move from full-feature PCs to Pocket PCs and then to WAP-enabled phones and back again. Fortunately, Microsoft's development tools for .NET will provide some help here.

Development Tools
While I am surely biased, I believe that the developer tools are the most important part of the .NET vision. Without them, the servers, the building block services, and device independence would be difficult, if not impossible, to deliver. In the next section, I highlight some of the most important aspects of the .NET developer tools.

Moving from .NET Vision to .NET Reality
From a developer perspective, .NET development tools have three main components: the Common Language Runtime, the .NET Framework Libraries, and the Visual Studio development environment.

Common Language Runtime
The Common Language Runtime (CLR) is a .NET runtime environment that allows all the .NET languages to interoperate and also allows the developer to select the best language for a task, rather than forcing the developer to choose a particular language simply because it's the only one that provides a required feature. The CLR has three parts:

• .NET Common Type System (CTS). The CTS gives the languages their interoperability. It defines the type system rules for all .NET languages so that you no longer have to worry about type safety and whether a given type has the same attributes in different languages. Furthermore, every element is an object. Better yet, everything is derived from a single object: system.object.
• Metadata System. This is the glue that binds the components and the CLR together. The metadata system allows metadata to be persisted at compile time and then queried at runtime so that the CLR knows how to instantiate objects, call their methods, and access their properties. Finally, through a process called reflection, an application can interrogate this metadata and learn what an object exposes. This is similar to the way IDispatch and type libraries work in COM.
• Execution System. As you would expect, the execution system is responsible for running your code. .NET introduces a concept called managed code to describe code that runs under the control of the CLR. With managed code, the CLR provides functionality such as garbage collection, security, just-in-time (JIT) compilation, and debugging support.

Many people think that the CRL is a virtual machine similar to the Java VM. Nothing could be further from the truth. When you compile a .NET language, the compiler initially emits Microsoft Intermediate Language (MSIL). MSIL, however, is never executed or interpreted in any way. Rather, it is translated directly into native code�either explicitly when you install the application or by one of the .NET JITs when the application first runs.

.NET Framework Libraries
The .NET Framework includes the .NET Framework Libraries or the Base Class Libraries (BCL) that are shared across all the .NET languages. If you have worked with Microsoft Foundation Classes (MFC) or Borland's Object Windows Library, you will have a good understanding of the BCL. The BCL supports everything from defining the types (remember, everything in .NET is a class) to standard file I/O all the way up through providing more complex functionality such as SOAP support. This means that no matter which language you choose, you will have the same capabilities.

Although not technically part of the Framework Libraries, the Common Language Specification (CLS) defines the requirements that a language's compiler must follow for the CLR to run its applications. Because the CLS serves to ensure interoperability across .NET languages, it only deals with the externally visible aspects of a language and is mainly concerned with keeping one language from breaking another. Therefore, the CLS sets forth a rather limited set of requirements. To be CLS-compliant, a language must expose only CLS-compliant types (those defined by the .NET CTS) and must be able to use any CLS-compliant type exposed by another .NET language. As a result, nothing requires all the languages and their compilers to support every feature of the CLS. Therefore, even though all your .NET applications will work together regardless of which languages you write them in, some languages might implement more of the .BCL than others.

Microsoft will include four languages with .NET: C#, Visual Basic.NET, JScript, and Visual C++ with managed extension. Other companies are working with the CLS and producing .NET versions of popular languages such as COBOL, Perl, Python, and Eiffel. In fact, because the CLS is a public specification, nothing prevents you (or anyone else) from designing your own language.

Because C# is Microsoft's flagship .NET language, it does implement nearly every feature supported by the BCL. So while the .NET framework insures that all .NET languages are equal, C# is probably a bit more equal than others.

C#
C# was designed from the ground up to be object-oriented. While it shares the syntax of C, unlike C++ it is not simply an extension of a pre-existing language. Therefore, its designer did not have to make any compromises for backward compatibility. As I mentioned earlier, everything is an object, so unlike Java, C# doesn't require that you deal with the differences between primitive types and object types.

Okay, so C# will make the OOP purists happy. What about the folks who just want to be productive? First off, the primary C# design goal was to provide the power and flexibility of C++ while maintaining the ease of use and RAD functionality of VB. Second, because C# syntax shares a common heritage with C and C++, picking it up will be easy for anyone with experience with any other C-like language. Even if you have not worked with C, you will find C# easy to pick up because of its elegance and consistency. Better yet, read Tom Archer's Inside C#. His lucid writing and liberal use of clear examples will quickly bring you up to speed.

Once you're familiar with C#, you will see that it will change your approach to software development. Strictly from a code-warrior level, .NET is all about language interoperability. I can write a class in C#, subclass it in VB, and finally use it from a Web page written in ASP.NET that uses the Adaptive User Interface (AUI) to output HTML to a WAP-enabled phone. And I won't lose any fidelity along the way. As a result of C#, people will start mixing and matching languages within a given project and probably even within a single tier of an application. Why? Simply because this is what's possible when you're no longer locked into using a single language.

For example, let's say that I need to process some Web logs to perform statistical analysis based on the length of a user's session. The first thing I might want to do is remove all the extraneous noise from the logs, such as requests for images and style sheets. To do this, I would probably use Perl because of its superior string handling. However, when it comes time for the heavy lifting of sessionizing the logs and doing my statistical work, I might choose something like C#.

When you start moving in this direction, you will find that you need to pay much more attention to the design of your base classes. These days, we can get away with less-than-robust class structures because code re-use in the real world is limited by language incompatibilities and platform differences. In a .NET world, all those problems go away, and you will come to rely on your base classes more than ever.

As you prepare for C#, I strongly recommend that you revisit some of the standard OOP concepts such as encapsulation, abstraction, polymorphism, and most important, inheritance. I know what you're thinking�that stuff is old hat; you think you have it down pat. After years of bad habits fostered by developing in �object-compromised� environments, your OOP skills are probably not what they used to be. I know mine weren't. Anticipating this, Archer's first chapter, �The Fundamentals of Object-Oriented Programming,� is the perfect refresher to make sure you still have those good design skills.

Conclusion
This month I started off by explaining the key components of the .NET vision: servers, building block services, devices, and development tools. After outlining the vision, I discussed the key .NET development components, including the .NET Common Language Runtime, the .NET Framework Libraries, and Microsoft Intermediate Language. I concluded with a brief discussion of C# and how language-independent .NET will fundamentally change the way you develop software.

Microsoft Press provides in-depth documentation for these and all the other issues related to developing for .NET. For a complete list of .NET titles from Microsoft Press, see the Inside Information on Microsoft .NET page.

The best place to start is with Tom Archer's new book, Inside C# is the authoritative guide to programming with C#�the language on which the .Net Platform is built.

Microsoft C# Language Specifications contains the complete specification for C#.

For detailed information on all Microsoft Press Windows 2000 titles for developers, visit the Windows 2000 for Developers page. For a complete list of all the developer titles, see the Developer Tools section.

For more information on Microsoft Visual Studio.NET, see the Visual Studio Next Generation Home Page. To get started right away, you can download the Microsoft .NET Framework SDK Beta 1. One great way to learn more about the .NET SDK is to review the slides from last summer's Microsoft Professional Developers Conference. For peer support, you can access several .NET newsgroups,  including one devoted to C#.

Microsoft C# Language Specifications contains the complete specification for C#.
Table of Contents, Sample Chapter