Finding Out About .NET

Monday, 05 August 2002

Just as Prince renamed himself as some symbol which cannot be pronounced or typed into Microsoft Word, I dislike the name .NET for similar reasons. It's not a word, it just makes my sentences look ugly. Starting a sentence with .NET just doesn't look good because of the double period. .NET with an apostrophe is even worse. .NET's name is the worst thing about it, except for possibly the hype.

I can't recall how long Microsoft has being advertising the .NET new wave. No-one had any idea what .NET was and, to this day, many people still don't. I ignored it because I heard a lot of people saying that it was just Redmond hot air; style and no substance. Indeed there was a time where .NET was hot air (although maybe it hasn't changed that much), but the technology is very real now and I was finally convinced it was worth looking into a few months ago.

I don't know why I'm bothering to write this article, because I don't think it's easy to understand what is special about .NET through sound bites. This was probably Microsoft's problem in the beginning who spent all their time glorifying its ramifications to the world, without trying to explain what it actually was or how it might accomplish such lofty goals. The only way to really get a good grasp of the technology is to read up on the subject; the book I chose, which only assumes a familiarity with Visual Basic, was Introducing Microsoft .NET. It attempts to confer an understanding of the technology and is not a reference manual or training guide. It was pretty good at that, although the author's sense of humour would occasionally bug me (a quarter-page footnote on page 160 dedicated to nothing but a joke is a bit too far).

I've not really done very much with .NET yet, in fact, but I think I've pieced together a picture of what .NET is. However, if I just go ahead and say what you can use .NET to do, I'll sound just like Microsoft spin. Instead I'll tell you what I've learnt about its components which leaves me writing this somewhat in reverse.

The CLR: Serving Everybody

Right now, you can download the .NET framework from Microsoft for free, which automatically sounds like .NET is a Windows-based technology. The most important thing to realise is that the underlying technology of .NET is not aimed at any particular platform and has published standards. This means that someone could build a .NET framework on other platforms which would expand the reach of .NET beyond the Windows empire. This isn't fantasy: Ximian is leading the development effort of Mono, an open source .NET framework for Unix/Linux.

Where to start? Instead of talking directly an operating system or function libraries, your code would talk to the core of .NET, a virtual machine called the Common Language Runtime (CLR). This would process all of your calls to the operating system and other libraries. This means code is managed and has a number of very important benefits. First of all, executables no longer have absolute control over the system. The CLR will be running OS calls for the executable and users have the ability to permit and deny operations per application. Second, the CLR covers operating system functions, file input/output, window calls, system date/time and so on. This means if the full CLR was implemented on Linux, .NET code that was developed on Windows could conceivably run on Linux.

There is another important point. The CLR is also language-independent. In fact, it runs something called Microsoft Intermediate Language (MSIL); all code that you build for .NET must be compiled into MSIL code. Unlike Java, the CLR does not interpret MSIL, it will compile it before execution. MSIL is the reason why you see all of the Microsoft development packages suddenly going .NET crazy. You cannot build .NET applications without having a development environment that supports the CLR class libraries and compiles code into MSIL. Visual Basic 6 is replaced by Visual Basic .NET, Visual C++ becomes Visual C++ .NET. Other languages are following with .NET support. For example, the Eiffel language, an object-oriented language with built-in support for the Design by Contract methodology, is now available as Eiffel for .NET.

There are other features of the .NET framework that enhance the strength of this virtual platform. Garbage collection is standard with the CLR; no more tracking down memory leaks or other headaches of memory management. Also, the CLR now eliminates the shared DLL problem with version awareness; we all know that if we install a new application, it may replace shared DLLs with newer versions which could actually break your existing applications. The .NET framework will maintain different versions of the same DLL just to make sure applications old and new are happy. If you compiled your code with the 23-Oct-2003 version of blobxp.dll, and a client computer doesn't have this particular version, the CLR will know this and complain. No more applications killed off by new installations.

ADO.NET: Database Access

When I used to program with Microsoft Excel VBA, I used ADO (ActiveX Data Objects) to access databases. This technology has been overhauled to become ADO.NET and, as a result, works quite differently. These ADO.NET objects form part of the core of the CLR and they support what can be called disconnected data access. What that means is that when you don't have direct access to the database - over an internet connection, nothing is immediate - things have to be handled differently. Although you might have retrieved 20 records for a user to review, you would only want to transmit the single change that the user made back to the server, to save bandwidth. Previously, this would be the programmer's responsibility, but now it's part of the ADO.NET infrastructure.

Going further, tables can become automatically typed as objects inside your code. That is, instead of having to explicitly map your column names to variables inside a data structure, it's already done in the language. Author.Name will actually refer to the Name column in your row from the Author table. If you're lucky enough to use Visual Studio .NET, you'll also find that Intellisense is extended to work with this. If you're not familiar with the term, Intellisense is the codeword for what happens when you type, for example, an object name into Visual Studio: a list of object members and methods will pop-up as you type, reminding you immediately of what you can make use of inside an object. Now it appears to work also for these typed data sets. All of the possible columns on the Author table appear after you type "Author." into the editor. In general, less SQL will be necessary as ADO.NET can do the work for you. (Of course, if you use a highly normalized database, you're still going to have to do a lot of work putting together your fields.)

Hold your horses, though. I still need to do some digging to distinguish between what is available for developments based on Microsoft SQL Server and those on other database systems. ADO.NET has a separate class for SQL Server and it makes me nervous. Remember that I'm still learning, these are just my first impressions. I'll let you know what I find later.

ASP.NET and Web Services: Internet Applications

Some web sites are run using Windows machines with Microsoft Internet Information Services (IIS) as a web server. IIS handles intelligent web page presentation through the form of Active Server Pages (ASP). You are no doubt familiar with many pages on the web that end with an .asp extension; they can prove difficult to call up from your web cache because they are generated on-the-fly by the server. Microsoft has upgraded this technology to become another .NET component, ASP.NET.

There's not much I can say on this subject, because I'm not particularly familiar with IIS or ASP to begin with. I've seen a few examples of ASP.NET code and it does seem that developing code for a web site which, say, handles multiple users who can request data, is fairly easy to construct. For example, cookie handling is encapsulated by .NET objects.

Internet applications need not be restricted to the web browser, however, and this is where web services come in. If you want to build a desktop application which connects to a server far away, then the approach needs to change. You need to create server code and client code; these must somehow communicate. The .NET web services components provide pre-fabricated infrastructure to support development.

Further, Microsoft has selected XML as the common language for all of these applications to communicate in. Everything talks in XML and I get the feeling that this might be a key point that I haven't fully grasped yet. It may be enabling different applications to talk to each other, thus circumventing the need for a complex middleware package. I need to understand this more to see whether this really is significant.

Apart from creating static HTML pages, I've never ventured into web site programming. I'll be interested to see at how quickly I can pick this all up with .NET.

The Big Idea

So why all this effort? As the name suggests, the technology is dedicated to bringing web applications to life, making the development process easier. Due to the open nature of the internet, connecting many machines with different hardware and software platforms, .NET needed to address problems involved with cross-platform, cross-language development - the public definition of the CLR enables this. ASP.NET and web services allow developers to create web applications through the browser or custom applications while database access, an integral part of any standard business-oriented web site, is supported through ADO.NET. With all of these components working in harmony, web programming should be significantly easier.

But .NET goes beyond that, especially as the Windows Forms technology is also embedded into .NET. I think Microsoft hopes it will become the de facto standard for Windows development in future. It is an attempt to solve many common problems with development and software maintenance. Many of the solutions offered by .NET are not new, but putting them together and integrating them so well is new. Microsoft .NET is a smart collection of components weaved together into a single, seamless entity: a brand new platform on which developments can be built.

That's what I see .NET as. I now challenge you to come up with your own quick summary of .NET, without sounding like a marketing mouthpiece.

Isn't There Any Bad News?

Of course, I left the best bits to the end. Here are some things which might make one hesitate over joining the .NET club.

First, let me point out that you don't have to buy Visual Studio because you can download the .NET SDK for free over the web, so nothing wrong there. The catch is, though, that the .NET framework, a required download for users to run .NET applications, is around 20MB in size. And it doesn't come with any Windows distributions yet. I've got my nice shiny new Windows XP and there's no trace of the .NET framework. This means .NET applications for now would need to be distributed with the .NET framework - double the install, double the trouble?

Microsoft has insisted on renaming Passport as .NET Passport. Passport just started out as a common logon for a number of Microsoft-affiliated sites, such as Hotmail. One of the problems with the web is that each new site requires a new username, a new password and entering all those important personal details again. Microsoft suggested that a single logon, with the user in control of who can access their data, is the way forward. They might be right. However, Microsoft believed they should be the internet repository of everyone's data, through the creation of the .NET Passport. It didn't take long before the idea generated a huge backlash and Microsoft was accused of trying to take over the web (again). Microsoft have temporarily suspended these plans, now considering having other companies look after the repositories. The idea is not dead and I'm not surprised; .NET Passport support has been built into the .NET framework if a developer wants to use it. It's possible that some will view anything stamped with .NET with suspicion, although Microsoft's Palladium initiative is generating new anxiety...

Despite .NET being touted as your one-stop shop for internet programming, there is still some security you need to work on yourself. There is no encryption built into .NET which means if you are transmitting sensitive data, you still need to seek extra help in making sure that information can't be tapped in transit. This is not necessarily a flaw but if you're going to be dealing with credit card data, start reading up on encryption technology.

There's a worry about Microsoft control of the standards. Microsoft has made the .NET standards explicit, but some fear the goal posts moving later, damaging interoperability on competitive platforms. I'm not sure if this an issue or not; there is already some built-in leverage for IIS Windows-based web servers (ASP.NET) and Microsoft SQL Server (ADO.NET). I'm not quite clear as to Microsoft's direction on this, but for the time being I'm inclined to trust them, because this technology does appear open and well-organised.

Bottom Line

I think the biggest worry is that .NET is essentially still in its infancy. It hasn't caught on bigtime yet, so some problems with the concept may not have surfaced yet. Seems like I'm sold already, though. I have my copy of Visual Basic .NET and I'll let you know what happens next.