This documentation is archived and is not being maintained.


This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.


Greater Office

Microsoft's Initiative from a Developer's Point of View

A business acquaintance of mine recently returned from an extended stay in Malawi, Africa. He was completely surprised and amazed by some of the changes in Microsoft's marketing and strategic direction that had taken place in the intervening months. He had never heard of the .NET Framework. Unless, like my friend, you were incommunicado for the better part of last year, you've probably had some exposure to Microsoft .NET. With that in mind, I can only hope to add some perspective to your understanding.

Microsoft's latest and ambitious initiative is commonly called .NET (pronounced "dot net"). It consists of several key technologies that work in tandem with any existing Windows 2000 installation (Windows ME to follow later). From a programmers standpoint, .NET features the following changed or new tools:

  • C# - (pronounced "see sharp") a new programming language
  • ASP.NET - a completely new, improved version of Active Server Pages
  • VB7 - a more object-oriented version of Visual Basic
  • ADO.NET - an Internet-oriented release of Access Data Objects
  • CLR - the Common Language Runtime

It's important to note that .NET can be run side-by-side with previous code; it's not a complete replacement of the existing machine configuration. This allows for easy testing and the gradual rollout of this technology.

The More Things Change...

Remember Microsoft DNA? Not long ago the official pronouncement from Redmond was that COM/DCOM was a panacea for software developers everywhere. To give credit where it's due, COM was a great idea. DCOM, on the other hand, did not catch on because of changes precipitated by the Internet. As more and more organizations began to work with one another, opening up portions of their internal networks to Internet traffic, the need for "demilitarized zones" and firewalls grew stronger. DCOM and firewalls did not mix.

Microsoft had a good model for homogenous Windows networks, but nothing that could really oppose the threat of Java, UNIX, and open standards like XML being carried across protocols like HTTP (itself an open standard). In addition, Microsoft is facing a court-ordered breakup. Last but not least is the threat that Internet-age customers will find other vendors to address their problems.

Seems that those are plenty of reasons for a shift in the strategic direction at Microsoft. This shift started in small increments and has gained speed in the last two years. Some key product groups began to focus on the concept of "software services" - a UNIX-like approach.

As anyone familiar with the UNIX environment will attest, the concept of a "service" is almost a foundation of that operating system. Let me clarify. I'm not intimating that Microsoft is giving up on the shrink-wrap business. Windows is still the cornerstone, and Windows is shrink-wrapped (if only the license). However, plenty of indicators pointed to serious customer defection over time. Some key voices in the industry noted three or four years ago that our computing paradigm would shift again. Users, no longer tied to PCs and applications like Microsoft Office, would take advantage of applications and applets offered free, or at almost no cost, by Internet companies like Yahoo. I was skeptical, but as I get used to working in the Web free-for-all, I wonder why customers should put up with Outlook when they can manage contact information via Yahoo through a cell phone, PDA, or Web browser.

About four years ago, Microsoft was able to persuade one of the foremost minds in the world of software development to join its ranks. Anders Hejlsberg, for many years the most creative engineer at Borland, and designer of Turbo Pascal and Delphi, would play a pivotal role in the portion of .NET that affects developers using Microsoft tools.

Common Language Runtime

The stage was set for fundamental change at Microsoft. More than a thousand development-related employees worked on probably the single-largest reengineering effort undertaken in Redmond. It's no exaggeration to say Microsoft's future is riding on it. What looks to be a cohesive, well-organized, and well-planned process was probably a number of different internal projects harnessed into the Common Language Runtime (or CLR).

What is the CLR? Didn't we have enough trouble with the VB Runtime? Now we want to extend the problems to the operating system? No; the CLR is a good thing. It gives Microsoft the ability to allow any programming language to manipulate the OS and its services. Like to work in Perl? No problem! How about Eiffel? Sure (although not many people have heard of it). VB? Python? Tcl? No problem (in time).

What about Java? Probably not - and I'm only half kidding here. Remember that the run-time layer allows us to proceed from API-driven programming to component-driven programming. Did you ever have to declare a funky API call in Visual Basic in order to address some functionality that you needed in your application? That's API-based programming. The advantage that comes with the CLR and .NET Framework is that the entire OS is encapsulated into a series of services or libraries. With that layer of abstraction between the programmer and the operating system, it becomes much easier to create plug-and-play modules for different languages.

C# Plays Very Well

I don't know if it was serendipity or careful planning that teamed Anders Hejlsberg with four or five top-notch engineers on a project that would create the next important aspect of the .NET Framework: the C# programming language. It gained considerable acceptance at Microsoft and was used to build ASP.NET. I predict C# - as the most recently created major language, incorporating Microsoft's best thinking on programming, and with Anders Hejlsberg's participation - is going to catch on in a big way with organizations working in Windows. A number of VB developers will make the change to C# since it is a new object-oriented language without the baggage of VB - and without VB's undeserved reputation as a toy language.

As developers investigate C# and .NET, some say that C# and its architecture copy Java and the Java run-time environment. While there are certain similarities, make no mistake: Microsoft isn't about to build a Java clone. You will see marketing campaigns arguing that Java is no longer relevant: "Why worry about Java when you can do anything you want with the language you already know - whatever it is?" Include tools that help Java developers in adopting .NET, and the offer gets tempting.

The most important point is that Microsoft's business is Windows, and Java's reason for existence is "write it once, run it anywhere." Sure; that was an overstatement in the era of desktop machines and client/server computing, but Java has come into its own in the Internet's "software as service" world. A programmer can use Windows and Forte on a laptop to develop code in Java that will be deployed on a UNIX server - or on an IBM AS/400. Microsoft's approach will let that programmer use any language to write code that can be run only on Windows servers. See the difference?

Would you call that a change for the better? I would. I believe the pressure on Microsoft from the Internet, competitors, and the Department of Justice influenced this change of strategy. In the end, it benefits the programmer who makes a living with Microsoft tools.

Yet Another Acronym?

I've become cynical when it comes to the alphabet soup of Microsoft acronyms, but .NET is more than another acronym. It will affect the way you work. Microsoft embraced HTTP, HTML, XML, and IP - some of the same open standards that are driving the Internet. Note that DCOM is not on the list. .NET is sufficiently radical that it was rumored Microsoft had abandoned COM as well. That rumor was unfounded, however. My only concern is that Microsoft will revert to its old modus operandi and "embrace and extend" its way to a hybrid standard that is essentially proprietary.


In the summer of 2000 Microsoft released a technology preview of the .NET Framework at its Professional Developers Conference (its acronym is PDC) in Denver, Colorado. Several months later the first public beta of Visual Studio 7 came out. It may sound odd, but having worked with the preview of the .NET Framework, Visual Studio seemed to get in the way - at least for Web development.

Many Web sites are built using tools other than VS (I use EditPlus for example). So I was delighted to see that one can generate ASP.NET pages with a simple text editor. Some of the salient improvements and new features include:

  • All ASP.NET code is compiled automatically behind the scenes, so it's faster than ASP code. Previously if you wanted to compile ASP-type Web pages, you had to use a product like Java Server Pages. In classic ASP, anything run once is compiled to disk. That is, the first person to access a script compiles it, but if a machine or a service restarts, the compilation process begins again when accessed by a user. In ASP.NET, components and scripts have their compiled image written to disk, so compilation persists.
  • ASP.NET is free-threaded. What a marvelous improvement! Finally we can store state information or database output in something more than a simple array. Being free-threaded allows the programmer to store business objects at the session or application level. You'll need to be judicious with it, but it allows for Web sites to be built entirely differently.
  • ASP.NET (and VB7) supports inheritance - real object-oriented inheritance, not the kind Microsoft has been selling in the past. You can design a form and inherit it in another page.
  • ASP.NET is programmed in VB or C#, not in VBScript. Obviously, this provides all the advantages of a proper programming language, e.g. strong typing, etc.
  • It's possible to build ASP.NET pages containing events, and even "code behind a page" like VB CBF modules. The ASP team also adapted to some problems that were found in building sites with ASP 3.0 and earlier releases. One property I liked immediately is named IsPostback. It knows if a page is being rendered after having been posted back, so you don't have to spend time writing the extensive logic necessary to deal with postbacks.
  • ASP.NET contains validation controls that help reduce the validation code that has to be written for a given page. The controls are well designed, allowing you to capture individual errors and inform the user, or show a list of what needs to be fixed on a page before proceeding. A specific type of validation control allows you to tie your own routines to it. Of course, this means you can access a database, or do whatever you like, to validate user input.
  • ASP.NET comes equipped with HTML server-side controls that allow for great cross-browser compatibility. The HTML generated by ASP.NET is version 3.2, which is known for working well on a variety of browsers.
  • ASP.NET has much improved debugging capabilities, including a mode that recognizes the difference between a user browsing a page from the Internet, and a developer working on it locally.
  • ASP.NET includes the ability to cache output at a specific interval, which results in performance gains. Lookup data can be read once and then made available to all users. Component data or static table data, such as ZIP Codes, can be cached in this manner.
  • Deploying an ASP.NET application is done via a simple X-copy command. In a typical ASP 3.0/COM application, the server has to be stopped, the COM objects copied, and re-registered. Anyone who has moved a complex application from development to a production or hosting environment will confirm that it can be cumbersome. The simplicity of ASP.NET in this regard will reduce maintenance costs.
  • ASP.NET features much-improved state management, including the ability to define a Microsoft SQL Server database as the storage mechanism for state information.

That's quite a list of improvements. In the last two years, I've built sites using the popular approach of separating a site's business and data access logic into custom DLLs. Unfortunately, if these components were changed, I had to re-register them, which occasionally meant bringing the entire site to a halt. One of many features of ASP.NET that really hits home is the ability to drop new or changed code into an existing site. The next user accessing the page uses the new version which runs on a new thread. The previous versions and new versions co-exist in memory, each occupying their own thread. Of course, the ASP.NET environment will eventually finish all user requests communicating with the old component, and quietly shut it down by no longer accessing it or directing memory to it.

Similar to Java Server Pages, ASP.NET uses XML-based configuration files, not binary files with proprietary editors. This allows developers to build applications without remote-access tools, and opens the possibility of copying settings programmatically from server to server - a particularly welcome change in the case of server farms.

VB.NET Language Engine

There's a difference between VB as a language and Visual Studio, the host of choice for that language. Using the .NET Framework, you can write VB code with Notepad. Of course you don't have the conveniences that come with Visual Studio, but as previously mentioned, after having worked with simple editors to produce Web sites, VS sometimes just gets in the way.

I won't go into great detail here; there will soon be many books covering VB.NET and the new Visual Studio release in greater depth. The best illustration I've found showing how VB is used to build Web sites under the .NET Framework is the IBuySpy Web site (, produced by Vertigo Consulting for Microsoft. IBuySpy allows complete visibility of its code and architecture, in both VB and C#, and is a marvelous learning tool. Other sites with good coverage of this subject are and, the latter in German with English translations.

It should be noted that as a Web developer in the .NET environment you are given the opportunity to write code interchangeably in VB.NET, C#, or even JavaScript. Imagine, an ASP.NET Web site containing JavaScript that can call a C# object, which in turn could call a VB.NET object residing in another source file on that site...

By now you are probably tired of hearing of Web services. A Web service gives your customers or partners the ability to access code on your server from their server, then run it and return data to their machine. It's the concept of DCOM, but uses XML for a cleaner, lighter-weight approach.

Microsoft, IBM, and others have co-signed the Simple Object Access Protocol Standard (SOAP), which defines how machines can exchange information in this manner. .NET makes writing a SOAP-based Web service a snap. Simply write your function and save it to a file with the extension of .asmx. Any potential consumer of this function, when browsing the .asmx page, is presented with a list of the inputs required by the function, as well as its return values. On paper it sounds wonderful. We'll just have to wait and see how this will work out.


Although a relative, ADO.NET is quite different from ADO. Most differences were designed with the Web or, if you're a stickler, with highly scalable distributed systems in mind. ADO.NET introduces the concept of memory-based datasets that can include tables, as well as the relationships of those tables. You'll never need to pull a recordset per single entity or relational set of columns. Instead you can pull the contents of all tables in your database for a given customer - if you choose.

I have a feeling that with all the hoopla surrounding ASP.NET and VB.NET, the ADO.NET improvements will fall through the cracks. Some of the important features of ADO.NET include its ability to:

  • use the DataSet object, which can contain one or more tables represented by DataTable objects, hence the idea of being able to load an entire database into memory (I'm exaggerating a little).
  • support the DataRelation object to associate rows in one DataTable object with rows in another DataTable object.
  • communicate to a database with standardized calls to the DataSetCommand object, which communicates to the OLE DB provider. Or in the case of Microsoft SQL Server, it may communicate directly with the server.
  • use the strongly-typed programming characteristics of XML.
  • transmit a DataSet with an XML file.
  • use HTML-based XML, which - unlike DCOM - can pass through firewalls.
  • increase application scalability, because access to the database isn't maintained as a connection. Instead, ADO.NET uses disconnected access without retaining locks or connections for lengthy periods.

ADO.NET now ships with a specially tuned SQL Server provider that, to the best of my knowledge, bypasses OLE DB to communicate with the server. This is a noteworthy point when speed and scalability are critical, as they often are in Web development.

So How About It?

If you work anywhere near the Microsoft sphere of tools, you'll be using .NET technology within a year. It's an important step in the right direction, and will remove a lot of issues that developers had with using Microsoft tools.

We're no longer living in a desktop world. Our developer universe increasingly consists of numerous devices, some of which bear little resemblance to a PC: PDAs, cell phones, even talking refrigerators! Can you see .NET running a refrigerator? I believe .NET is a wonderful improvement over Windows. And if my clients want their refrigerators or PalmPilots or whatever to run Windows, I will use all the great functionality in .NET. Yet I'm left with one question: Which tool will allow me to be a productive programmer, without restraining me to the operating system of a given market? Especially since the once-homogenous market of Wintel is now splintering.

Thomas Wagner is CEO of eTechPartner Inc., a software development and systems integrator specializing in Internet and client/server applications. He can be reached via e-mail using