The general
consensus of some prior writeups seems to be that
Microsoft's .Net initiative is to be despised. Perhaps. In the interest of
completeness, however, I'll add at least an
outline description of what .Net is. I'll strive for
objectivity, but without
guaranteeing that I'll achieve it.
Thanks in no small part to Microsoft's own
marketing droids, the actual
definition of the term ".Net" has been allowed to become somewhat
confused in many minds. There seems to be some
opinion, for example, that .Net=
Passport. But while the Passport service runs under the .Net
environment, and is developed with .Net development tools, the two are not
synonymous.
From the developer's perspective, .Net consists of 3 components: the Common Language Runtime or CLR, the Framework Class Libraries, and .Net compliant Development tools. These are each briefly described below.
The CLR is the runtime environment of .Net, and, as such, is analogous to the Java Virtual Machine. Where the JVM is cross-platform, however, the CLR attempts to go one better by being cross-language. .Net executable code is known as Intermediate Language, or IL, which is the output product of all .Net-compliant compilers, and is analogous to Java Byte Code. This IL code is Just-In-Time (JIT) compiled within the CLR, which also provides caching services so that code pieces used multiple times don't have to be repeatedly recompiled. The CLR also provides non-deterministic garbage collection services, which Java has offered for years, and may be one reason that .Net is considered a ripoff. Code running under the CLR is said to be managed code, because its access to memory and other resources is managed by the CLR on the application's behalf. The CLR also administers the handling of different levels of trust, the idea being that you will grant a lower level of trust to code gotten off the internet, thereby preventing potentially malicious access to resources like disk and memory. We can count on any weaknesses in Microsoft's implementation of this scheme, which resembles the idea of the "sandbox", being discovered, broadcast, and exploited more or less instantly. As of the time of this writeup I am aware of several ongoing attempts to implement the CLR on other OS's and platforms, so that the CLR will be cross-platform as well as cross-language. This cross-language functionality is heavily advertised by Microsoft, and means that classes, modules, data-structures, and so forth, that are defined in one language may be instantly and effortlessly reused from within another, without the nightmarish plumbing that would be necessary to do this with their earlier COM technology. Microsoft's ultimate demo will be to compile a class in Visual Basic and then turn around and run it on a Mac or Linux box. I have not seen such a demo yet.
The Framework Class Libraries are, again, very analogous to similar libraries provided for Java implementations. They wrap and extend the Windows API, and provide all of the needed services for things like graphics presentation, peripheral interaction, threading, distributed objects, and so on. They are a vast set of libraries, and are wherever possible CLR compliant IL code themselves, but still have an irreducible core of native code.
.Net compliant development tools consist of the compilers and supporting tools. You do not have to use the Visual Studio .Net IDE to develop .Net applications. When I began working with the beta 1 release of the .Net SDK, the Visual Studio release was not included, and we compiled from a command line just like in the old days. The Visual Studio release, when it did come, had astonishing sytem requirements for processor speed and disk space, and was very much bloatware gone out of control. At any rate, Microsoft distributes 3 .Net compliant languages:
C# (pronounced C-sharp), is extremely similar, though not identical, to Java. It is the "premier" .Net language, and is explicitly positioned as a Java competitor.
C++ is the only language distributed with Visual Studio .Net that can generate "native" instructions. To produce CLR compliant IL, you must include what Microsoft calls "Managed Extensions", which, of course, are specific to .Net and Microsoft proprietary, and which drive standard C++ purists up the wall.
Visual Basic .Net is more or less completely incompatible with earlier versions of the language, which irritates VB developers with a lot of legacy code. It has been redesigned to incorporate some of the object-oriented features implemented by the runtime, such as inheritance, and is therefore now somewhat isomorphic with C#. Which raises the inevitable question of why you'd need both. And, indeed, there is a school of thought that Microsoft's surreptitious intention is to coerce VB programmers into becoming C# programmers, which would turn C# into a weapon aimed right at Scott McNealy's heart. Okay, that last bit is over the top, but you get the idea. There are an awful lot of VB programmers, though, and how they'll react to this is an open question.
There are many, many details about .Net I've left out completely, such as attribute based programming and reflection, the .Net version of ASPs, ADO, which is the managed code class library for database access, and on and on and on.
And a larger question remains also about Microsoft's ultimate intentions. They've made it no secret that their grand vision involves turning software into a service. In other words, you won't buy your software, you'll only subscribe to it. Which is an idea I am not personally wild about at all. I recently found a quote on a bulletin board, though, which I'd attribute but I can't remember who should get credit: "For years, Bill Gates has dreamed of finding a way to make the Chinese pay for software."