What Is .NET?

When you first hear or read about .NET you may be a bit confused about its scope. What precisely is .NET? What technologies and products comprise .NET? Is .NET a replacement for COM? Or is it built using COM?

There is no simple answer to what .NET is. Microsoft has really blurred the boundaries of .NET, which is of course something you all know and love the Microsoft marketing division for. Ask any group of developers what Windows DNA is, and you'll get fifteen different answers. The same confusion is now happening with .NET. To make the confusion worse , Microsoft has dropped the Windows DNA name , and re-branded most of their server products (such as SQL Server 2000 and BizTalk Server 2000) as part of the all-encompassing Windows Server System . This has left many people thinking that .NET is just DNA renamed , which, of course, it isn't.

The Pieces of .NET

The way to cut through this confusion is to divide .NET into three main areas:

• The .NET vision : The idea that all devices will some day be connected by a global broadband network (that is, the Internet), and that software will become a service provided over this network.

• The .NET Framework : New technologies such as ASP.NET that make .NET more than just a vision, providing concrete services and technologies so that developers can build applications to support the needs of users connected to the Internet today.

• The Windows Server System : Server products, such as SQL 2000 and BizTalk 2000, which are used by .NET Framework applications but are not currently written using the .NET Framework. All future versions of these server products will support .NET, but will not necessarily be rewritten using .NET.

For developers, another important piece of the .NET platform is, of course, developer tools. Microsoft has a major new update of their premier development environment for .NET, called Visual Studio .NET. However you can still develop .NET applications using Notepad, or any other IDE, which is what a lot of the Microsoft development teams do.

The .NET Vision

For years now Microsoft has been investing heavily in the Internet, in terms of product development, technology development, and consumer marketing. I can't think of any Microsoft product or technology that isn't web-enabled these days, and I can't think of any marketing material Microsoft has released that isn't Internet-centric. The reason for this Internet focus is that Microsoft is betting its future on the success of the Internet as well as other open standards such as XML succeeding and being widely adopted. They are also betting that they can provide the best development platform and tools for the Internet in a world of open standards.

The .NET Framework provides the foundations and plumbing on which the Microsoft .NET vision is built. Assuming the .NET vision becomes reality, very soon the whole world will be predominantly Internet-enabled, with broadband access available just about anywhere , at any time. Devices of all sizes will be connected together over this network, trading and exchanging information at the speed of light. The devices will speak common languages like XML over standardized or shared protocols such as HTTP, and these devices will be running a multitude of software on different operating systems and devices. This vision is not specific to Microsoft; many other companies, such as IBM and Sun, have their own spin on it.

The .NET Framework provides the foundation services that Microsoft sees as essential for making their .NET vision a reality. It's all well and good having a global network and open standards like XML to make it easier for two parties to exchange data and work together, but history has shown that great tools and technologies to implement support for standards are an important ingredient in any vision. Marketing drivel alone doesn't make applications; great developers with great tools and a great platform do. Enter the .NET Framework.

The .NET Framework is the bricks and mortar of the Microsoft .NET vision. It provides the tools and technologies needed to write applications that can seamlessly and easily communicate over the Internet (or any other network, such as an intranet) using open standards like XML and SOAP. The .NET Framework also solves many of the problems developers face today when building and deploying Windows DNA applications. For example, have you ever cursed at having to shut down ASP applications to replace component files, wished you didn't have to register components, or spent hours trying to track down binary compatibility or versioning problems? The good news is that the .NET Framework provides a solution to problems like these; no more registering components or shutting down applications to upgrade them!

Note

Windows DNA was the name Microsoft gave to their n- tier development methodology before .NET was launched. The name is now somewhat defunct , but the same principles (for the most part) still hold true in .NET.

Even better news is that the .NET Framework also solves many of the problems you're likely to experience in the future. For example, ever considered how you're going to adapt your applications or web sites to run on or support small hand-held devices? Have you thought about the impact of the up and coming 64-bit chips from Intel? Microsoft has, and these are all catered for as part of .NET Framework.

So, the whole push towards the Internet stems from Microsoft's belief that all devices (no matter how small or large) will one day be connected to a broadband network, the Internet. All will benefit in unimaginable ways from the advantages this global network will bring “ your fridge could automatically send orders out to your local supermarket to restock itself, or your microwave could download the cooking times for the food you put in it, and automatically cook it. Wouldn't that be cool (or, in fact, hot)?

These ideas might sound a little futuristic, but manufacturers are already working on prototypes . Imagine that you were part of a team working on one of these projects. Where would you start? How many technologies and protocols would you need to use? How many languages? How many different compilers? Just thinking about some of these fairly elementary issues makes my brain hurt. However, this is just the tip of the iceberg.

If a fridge were going to restock itself automatically, wouldn't it be cool to have it connect via the Internet to the owner's local supermarket, or any other supermarket available in some global supermarket directory? The supermarket systems and fridges would need to exchange information in some standard format like XML, ordering the goods and arranging delivery. Delivery times would have to be determined, probably by the fridge, based upon the owner's electronic diary (maybe stored on a mobile device or in a central Internet location “ using My .Net Services, for instance), telling the fridge when the owner will be at home to accept the delivery.

Mad as it sounds, I do believe applications like this will be available and very common in the next five to ten years. Your lives as developers really are going to change a lot in the future, especially when web services are widely adopted. I doubt if you'll all be programming fridges (although I know of people who are), but the Internet has already changed your lives and careers dramatically, and that change isn't slowing down. More and more devices are going to get connected, and if you are going to adapt quickly to these changes, you need a great toolset that enables you to meet the time-to-market requirements of the Internet, and a toolset that also provides a consistent development strategy, no matter what type of development you're doing.

Let's take a look at the former Microsoft Windows Distributed interNet Applications (Windows DNA) platform, and see why the existing platform and the tools need to be revamped for some of this next generation of web-enabled applications.

The Problems with Windows DNA

Microsoft Windows DNA architecture started back in late 1996 and early 1997, when Microsoft began to recognize the potential of the Internet. They released Windows DNA to help companies embrace their vision (and of course sell their platform).

Note

Windows DNA was a programming model or blueprint that companies could use when designing n-tier distributed component-based applications for the Windows platform. At that time, development of .NET had already begun inside Microsoft, although back then it was called COM+ 2.0.

Windows DNA applications did not have to use the Internet, but the Internet was the primary focus for most companies. Over the years Windows DNA grew and came to cover the various Microsoft products and services that could be used in an n-tier application to provide functionality such as messaging and data storage.

The problem with Windows DNA was not the blueprint for design; indeed, the same n-tier designs still apply for .NET applications. The problem with Windows DNA was that the enabling toolset provided by Microsoft and others was primarily based upon old technologies like COM, whose origins date back to the early nineties, and the Win32 API utilizing proprietary languages and protocols “ a bad thing these days, as you all know. This is, at least initially, rather surprising. But just think of the pains you go through as a developer today when building web applications. Do you think the Windows DNA platform is easy to use? Do you think the platform is consistent? The answer is, of course, a resounding no .

Let's review some of the most common problems associated with Windows DNA, and touch briefly on how .NET solves these problems. With a few of them covered, we'll really start to drill down into the driving technology behind .NET and the CLR. You'll see how these lower-level technologies really drive and enable the development of higher-level technologies such as ASP.NET.

Stopping 24 x 7 Applications

Have you ever tried replacing a COM component on a production web server? Or even on a development machine? Prior to .NET, to do this you had to stop the entire web site, copy a file across, and then restart the web site. Even worse, sometimes you had to reboot a machine because COM and IIS just seem to get confused, and do not release files correctly. This is a pain during the development of an application, and is unacceptable for production sites that must always be running. This problem is caused by the way COM manages files such as DLLs “ once they are loaded, you cannot overwrite them unless they are unloaded during an idle period, which of course may never happen on a busy web server.

.NET components do not have to be locked like this. They can be overwritten at any time thanks to a feature called Shadow Copy , which is part of the CLR. Any applications you write, as well as Microsoft technologies like ASP.NET, can take advantage of this feature; this prevents Portable Executable (PE) files such as DLLs and EXEs from being locked. With ASP.NET, changes to component files that you create and place in the bin directory “ this is where components for an application live “ are automatically detected . ASP.NET will automatically load the changed components, and use them to process all new web requests not currently executing, while at the same time keeping the older versions of the components loaded until previously active requests are completed.

Side - by - Side

Another difficulty with Windows DNA was that it was not easy to run two different versions of the same application components side-by-side, either on the same machine, or in the same process. This problem is addressed by Windows XP, but on pre-Windows XP systems you typically have to upgrade an entire application to use the latest set of components, or go through some serious development nightmares.

.NET allows different versions of the same components to co-exist and run side-by-side on the same machine and within the same process. For example, one ASP.NET web page could be using version 1 of a component, while another, version 2 (which is not compatible with version 1, but for the most part uses the same class and method names ). Based upon the dependencies for the web page (or another component) that is using this component, the correct version of a component will be resolved and loaded, even within the same process. Running multiple versions of the same code simultaneously is referred to as side-by-side execution .

Note

Using side-by-side execution, you can run version 1.0, version 1.1, and all future versions of ASP.NET side-by-side on the same machine without conflict. The same is true for the .NET Framework itself.

Scripting Limitations

If you're an ASP developer who is not familiar with writing components (if at all), you have probably found it annoying that you can't do everything you want to from within an ASP page. You may have had to write, find, or buy components to expose the necessary functionality to your pages, such as registry access and security, which, at the end of the day, are all a standard part of the Windows platform.

This problem is caused because ASP pages can only be written in scripting languages, which cannot directly access the Win32 API, and also have many COM- related restrictions. This can be a real pain if you haven't got the resources or time to invest in component development. Wouldn't it be nice if you could do everything within an ASP page, and just use components when you have time, and when there is a benefit such as common code reuse? Well, with ASP.NET, you can take that approach.

ASP.NET pages can use all of the functionality of the .NET Framework. You no longer have to write components to work around the problems of the scripting runtime (since there is no scripting runtime any more). You can decide what code goes into an ASP.NET page, and what goes in your components. There are no scalability issues with code in ASP.NET page (but it still is good practice to create components for reasons of code reuse and maintenance).

Versioning Hell (DLL Hell)

Undoubtedly, the biggest problem with Windows DNA is versioning. When an application is built, it typically consists of many intricately related pieces such as standard DLLs, ASP pages, and COM DLLs hosting components. ASP page X might not be able to run without COM component Y , which requires DLL Z , which in turn is dependent upon more DLLs, or specific versions of object models like ADO 2.6. All of these dependencies are implicit (not documented, visible, or enforceable by the operating system), and have to be satisfied for an application to run smoothly.

If any of these application dependencies are broken or missing, the application won't function correctly, or “ worse still “ might break at runtime halfway through some important operation. Many components are also dependent upon system-wide DLLs shared by many applications, and values in the system registry. It is very easy to break applications by simply installing another application, or accidentally changing the registry using a tool like Regedit. Tracking down these problems can be a very difficult task, if not impossible .

To resolve versioning problems, .NET enables developers to specify versions and dependencies between different software components. These dependencies are stored along with the component code itself in an assembly (think of an assembly as something like a DLL or EXE file for now), and .NET uses this information to ensure application integrity is maintained “ reporting errors if components cannot be loaded, if missing dependencies are found, or even if it detects files that have been tampered with.

To further reduce registration problems, .NET no longer uses the registry for component registration. Information about the types (classes, structures, enums, etc.) is contained with the code, and this type information is retrieved directly from the files at runtime. When an application instantiates a new type, such as a business object, the CLR will scan the application directory for the component, and then look at other predefined locations for the component. Once a component is located, its information is cached (for performance reasons) and reused on subsequent requests. This decentralized registration reduces the chance that applications will interfere with each other by mistake, and also removes the need to register and unregister components. This makes deploying applications much easier, since all you have do is copy files into a directory.

Important

The .NET Framework supports shared components, although, unless you're a component vendor, these are not recommended. Shared components are installed in the Global Assembly Cache (GAC), which can be thought of as a system directory for holding component files.

Why Do You Need .NET?

The problems we've discussed here with Windows DNA are just a few of many that you've almost certainly encountered . These problems, combined with the inherent complexity of the Windows DNA platform, makes it a less than optimal platform for developing next generation applications, especially those that will run on non-standard devices like your fridge. Can you imagine the trouble you'd have to go to in order to actually implement the software required for an Internet-enabled e-fridge?

The good news is that .NET avoids many of the problems associated with the Windows DNA platform, by giving you a brand new Internet-centric platform.

.NET “ A Clean Start

When programming applications for the Windows platform, there are a myriad of programming languages and technologies that you can use. Depending on the chosen programming language, the technologies available are typically very different “ and can often be restrictive . For example, a C/C++ programmer who has to write a GUI application can use the Microsoft Foundation Classes (MFC) , the Windows Template Library (WTL) , or the lower-level WIN32 APIs. A VB programmer has to use the VB Forms package.

The problems with this approach are:

• Microsoft spends more time developing two or more competing technologies, rather than focusing on improving one shared technology.

• The availability of so many technologies that do the same thing can be confusing.

• Multi- faceted developers who know multiple languages have to learn multiple technologies to achieve the same results.

• Companies have to invest predominantly in one language, since cross-training can be time- consuming and expensive.

• Not all languages will necessarily expose the same functionality, or be as productive as each other. For example, with C/C++ and MFC you can easily write MDI applications with docking toolbars and windows. With VB, you have to buy a third-party package, or write the functionality yourselves. However, I can pretty much guarantee (from experience) that VB programmers are typically more productive because they spend less time debugging low-level pointer errors.

These issues, and many others, make the Windows DNA platform hard to understand. It often leads to confusion, and I know many companies that have chosen the wrong technology or language and then hit technical implementation limitations late in their schedules. Some people might argue that using C/C++ for everything is the best strategy, but then of course you'll probably miss your time-to-market goal because the developers are too busy debugging their code. There just aren't enough really good C/C++ programmers who actually want to develop business applications. .NET helps solve these problems.

With .NET there is now just one clean object-oriented way of accessing the functionality of the .NET Framework and building applications. All the best and most commonly used features of existing technologies have been merged together into a single framework, as shown in the schematic in Figure 2-1.

Figure 2-1:

For example, Windows Forms are used when developing GUI applications. Windows Forms is a consistent GUI framework that exposes the same set of classes to any language supported by the .NET Framework. All languages typically also have the same Visual Designers. This makes the development of GUI applications simple. Use one technology, and it does not matter what language you use. The same simplicity also applies to building web applications using ASP.NET. No longer do you have to choose between writing VB Web Classes, ISAPI Extensions, or ASP; just use ASP.NET. It provides all of the features application developers need and, again, all languages are equal and can access exactly the same functionality.

Of course, there are some downsides to .NET. If you're writing applications that require absolute performance, such as real-time applications or complete packages like SQL Server, .NET might not be the platform for you. Although .NET has huge benefits for the average application developer, it simply doesn't have the raw performance of a well-written C/C++ application; certain aspects of a .NET application (such as memory allocation), however, are faster than C/C++. For reasons of performance and investment, many Microsoft teams will not be rewriting their applications using .NET. Instead, they will be .NET enabling them. For example, in SQL Server Yukon you can write stored procedures using .NET languages such as VB and C#.

Important

VB Web Classes are not supported in .NET. They have been superseded by ASP.NET pages.

No More Language Functionality Debates

If you have programmed with VB before, no doubt you are aware that C/C++ is a much more powerful language for low-level development, and suffers from far fewer limitations than VB. With .NET, all programming languages are first-class citizens . This means you can implement solutions in a programming language that your developers are productive with, without any penalties. Version 1.1 of .NET consists of four languages shipped by Microsoft:

• Visual Basic .NET.

• C#.

• JScript.NET.

• Managed C++.

There are no significant technical differences between these languages; so again, it's a matter of personal preference and company benefits. One caveat to note is that some languages may perform marginally better (about 5%) than others. My tests have shown that C# is marginally faster than VB, and Managed C++ is faster than C# since it optimizes the output it creates. At the end of the day, performance really comes down to the abilities of the compiler writers to generate good code, and this is related to how long a compiler has been under development.

If performance is crucial to your applications, you may want to do some basic performance testing before choosing a language. One would assume that eventually all these languages will be as fast as each other, so I personally wouldn't recommend spending too much time worrying about this issue. Go with the language that will give you the most productivity.

Note

In case you're wondering, my language preference as a professional developer is C#. It's a clean, modern, and easy-to-use language that was designed specifically for the component-oriented world of the .NET Framework. It doesn't carry around any of the baggage or quirks of other languages such as VB and Managed C++.

No More ASP-Imposed Limitations

As stated earlier, there are many situations in ASP 3.0 where you end up having to create COM components. With ASP.NET, these limitations essentially disappear, since Active Scripting engines are no longer used and are replaced by proper type-safe languages such as Visual Basic .NET.

Anything that you can do from within a .NET class can be done in an ASP.NET page. This means that rather than having to always use components to develop your n-tier web application, you now have the choice of when, how, and whether you use them. This flexibility in ASP.NET stems from the fact that all ASP.NET pages are converted into classes and compiled into a DLL behind the scenes. Of course, the fact that you now have this newfound flexibility doesn't mean you should forget everything you've learned in the past. You should still use components to encapsulate data access and other common functionality used in your applications, and you certainly shouldn't go mad and do crazy things like trying to display a Windows Form in an ASP.NET page!

Multiple Platform Support

.NET has been designed with multiple platform support as a key feature. For versions 1.0 and 1.1 of .NET, this means that code written using the .NET Framework can run on all versions of Windows: Windows 95, 98, 98SE, Windows NT, Windows 2000, Windows XP, and so on. Depending upon the class libraries used, the same code will also execute on small devices on operating systems such as Windows CE, which will run a special compact edition of .NET. However, unlike Java, .NET does not promise that all classes will work on all platforms.

Rather than restricting the class libraries available in .NET to cover functionality that's only available on all platforms, Microsoft has included rich support for all platforms. As developers, it's down to you to make sure you only use the .NET classes that are supported on those platforms (although it's expected that Microsoft will provide tools to help with this process). Work in this area has already started with the definition of the CLS. Microsoft is working on the CLS with HP, Intel, IBM, and other companies, and so, who knows , you could also get non-Microsoft versions of .NET-compatible systems that run on other platforms.

An exciting prospect for companies is that the .NET code you write today will also work under 64-bit versions of Windows without change. If you ever had to port a 16-bit application to 32-bit Windows, you'll appreciate the time, effort, and pain this saves. This is possible since .NET natively supports 64-bit types such as System.Int64 , which in VB is called the Long type.

Targeting multiple platforms with .NET does introduce the potential for well-known Java-like problems to hit companies. Since the code is being compiled dynamically on different platforms, the compilation process will result in different native code. Even with the best intentions in the world, this could lead to some bugs appearing in code, especially if the Just in Time (JIT) compiler for a given platform has bugs or just compiles things differently. You should be prepared to QA your products on the .NET platforms you are going to support. Even so, the benefits and money saved by the reduced development time make this an exciting time.

Looking forward, it is expected that .NET will run on other platforms such as UNIX, although it is unlikely that the whole of the .NET Framework will be supported, probably just the languages and the base class libraries. Microsoft is keeping these plans very quiet at the moment, but they are on the table and they are being researched. Once again though, even if Microsoft does deliver .NET on a non- Windows platform, it's unlikely they will want to invest significantly in other platforms. The amount of functionality available to .NET applications on these platforms is likely to be reduced, so you might expect to lose COM+ services such as transaction support.

Performance

Since day one, an important design goal for .NET has been great performance and scalability. For .NET to succeed, companies must be able to migrate their applications, and not suffer from poor performance due to the way code is executed by the CLR. To ensure optimal performance the CLR compiles all application code into native machine code. This conversion can either be done JIT as an application runs, on a method-by-method basis, or when an application is first installed. The compilation process will automatically make use of the processor features available on different platforms, something traditional Windows applications could never do unless you shipped different binaries for different platforms.

With the first version of ASP.NET you could expect well-written web applications to run two to four times faster than equivalent ASP applications, with similar gains in the area of scalability. Version 1.1 adds a marginal increase in performance on top of that. In other areas of .NET, such as Windows Forms, performance is likely to be similar to VB6 for most applications, with memory usage increasing slightly due to overhead introduced by the CLR. As subsequent versions of the CLR and technologies like Windows Forms are released, you'll find that each release will have a smaller memory footprint and better performance.

Hopefully, by now you're starting to understand how .NET can help solve many of the problems developers face today when writing software. It replaces a lot of older technologies like COM and COM+ (although these are certainly not dead), with better-designed equivalents. At the heart of this new platform is the CLR.