The Guru[ap]s Guide to SQL Server[tm] Stored Procedures, XML, and HTML

That's a really good question. Microsoft has branded so many things with the .NET label that it's difficult to tell sometimes. Let me tell you what it means to me. First, the high-level view:

.NET is a set of technologies that

• Pulls together the best of the many disparate application development technologies, particularly those related to Web development.

• Unifies today's isolated Web applications and platforms.

• Dramatically improves developer productivity.

• Makes the same software design best practices available to Web developers that have been used successfully on other platforms for years .

• Provides a safe environment in which applications can run without having to concern themselves as much with resource management or low-level programming details.

• Corrects longstanding deficiencies in Microsoft's family of programming tools. Although Microsoft had a larger share of the developer tools market than anyone else, until .NET came to be, I do not believe they had the best products. In my opinion, that distinction clearly belonged to Borland. Having used both company's products for many years, I think I can say this, although I'm sure there are many who would disagree .

• Provides the tools to build apps that fulfill the stated vision of making information available anytime , anywhere , and on any device.

And now the specifics:

• .NET consists of a class framework, a family of programming languages, and the system-level facilities necessary to produce and run executable code and to share data between applications. The languages include Visual Basic.NET, C++, JScript, and a brand new language called C# (pronounced "C sharp"), an easier-to-use member of the C/C++ family.

• The .NET class framework (the .NET Framework) is an all-encompassing, extremely rich, object-oriented RTL (RunTime Library) that greatly simplifies and standardizes application development for any of the target platforms that .NET supports. It puts an object-oriented face on virtually anything you can do in a program. For example, rather than calling CreateWindow to create a window, or waiting in a message loop to process keys under Windows, you simply add a new WinForm to your project and drop controls onto it visually, as with Visual Basic. Unlike Visual Basic, though, the code behind the form is a true OOP class in every sense of the word. When you attach code to a button, you're coding a method of the form class. The WinForms architecture uses the same form-based delegation model that was originally pioneered in Delphi. You get object orientation and visual development in one toolsomething the current shipping version of Visual Studio does not have.

• All .NET languages are object-oriented. All support inheritance, encapsulation, and polymorphism, and all support interfaces as a separate language construct apart from classes.

• .NET languages are cross-compatible. You can create a class in one language and inherit from it in another. This is something we've never had before in the Microsoft family of development tools. You could use objects in one language tool that were created in another, but you could not extend an object created in another language through inheritance.

• All .NET languages support the same data types. The conversion issues we often run into now with sharing data between, say, a VB app and a C++ program are gone.

• All .NET languages support structured exception handling. If an exception is raised by a class, it's communicated properly to its caller, regardless of what language each is written in.

• In addition to the languages that will ship with .NET, Microsoft has provided an open API (the Common Language Specification) that allows third parties to build their own .NET-compliant languages. Several third parties have announced plans to do so. (I've seen probably a dozen or so third-party .NET languages announced in the trades. I know that both a Perl.NET and a COBOL.NET are planned, for example.) Each .NET language, regardless of who produces it, will have the same rich feature set as the others.

• Programs are compiled into MSIL (Microsoft Intermediate Language) by the .NET language compilers. This code is known as managed code. Managed code brings with it a number of intrinsic benefits:

  • Automatic garbage collection. Like the Java Virtual Machine, .NET's Common Language RunTime (CLR) automatically disposes of objects when they're no longer needed and the system needs to free physical memory. Unlike the Java VM, though, the CLR provides methods of controlling exactly what it does and when it does it. Objects can be excluded from garbage collection, and the frequency and scope of garbage collection can be controlled by the developer.

  • Bounds and range checking. You aren't allowed to overwrite memory you don't own.

  • The potential for the CLR to be ported to other platforms. Although this isn't high on most Wintel developers' lists, it would certainly be something most would like to have.

• When executed, a program is automatically translated to native code by .NET's just-in-time (JIT) compiler. This approach has a number of positive aspects, among them:

  • The compiler can generate different instructions for different processor chips. Instead of having to take a one- size -fits-all approach, the JIT compiler is free to generate code that's optimized for the chip on which it's currently running. For example, the JIT may produce different code for an Intel chip than for an AMD or Cyrix chip.

  • By waiting to produce native code until an app executes, the possibility exists that updates to the framework could improve the quality and performance of the native code that's generated without necessitating even a recompile of end- user apps. That is, as Microsoft's JIT compiler technology improves, your apps can improve with it without requiring you to recompile or redistribute your apps.

• .NET provides facilities for backward compatibility and interoperability with COM and unmanaged code.

• .NET makes creating distributed applications as easy as creating a GUI. .NET Web Services are XML and SOAP (Simple Object Access Protocol) based, but you do not have to deal directly with either of them unless you want to. You code to classes, and .NET takes care of the rest. Web Services are automatically discoverable across a network, and .NET will create the code necessary for you to use them as though they were local classes.

• .NET supports the creation of rich user interfaces for both the Web and Windows:

  • You design forms for either platform using a visual designer similar to the one in Visual Basic. You drop controls onto a form and attach code to them.

  • You can create your own controls that are descendents or composites of others.

  • For Web forms, you can decide in the visual designer whether a control resides on the server or on the client.

  • You can use ActiveX controls alongside .NET controls on the same form.

• The .NET forms architectures supports visual form inheritance. You can create a Web or Windows form and inherit from it to create other similar forms. You can override methods, treat the forms polymorphically, and so forth. This capability was, again, pioneered in Delphi (I don't count PowerBuilder Data Windows here because they weren't object-oriented). However, .NET improves on the Delphi approach by keeping the form inheritance based entirely in code. In Delphi, a complicated form-differencing algorithm determines the appearance of descendent forms at runtime because, as in Visual Basic, property settings are stored in a separate resource file for each form. Each member in an inheritance tree has to be examined and have his property settings checked to determine the impact on descendent forms. The process doesn't always work, and it's not hard to break it. In .NET, all property settings are stored in the class itself, so if you drop a button onto a form and set its caption, code is generated automatically that assigns the caption the value you specified. However, the Visual Studio 7 IDE is smart enough to fold that code out of view, so you don't have to wade through it while working. You get the best of both worlds : true OOP-based form inheritance without the headaches of having to trudge through reams of autogenerated code.

• Because .NET does not rely on the system registry, the deployment of applications has been greatly simplified. You may have heard of the fabled "XCOPY deployment." It's not a fable. It works. I've tried it. Because there's no registration requirement for .NET assemblies (.NET parlance for compiled binariesDLLs and EXEs), you simply XCOPY an application assembly and the assemblies it depends on to deploy it. Unlike COM, you can have multiple copies of the same .NET object assembly on the same machine. This Sdoesn't require any special hoop jumping or the kludges of side-by-side COM deployment and DLL redirection. It's not an afterthoughtit's the way the fra mework was designed to work in the first place. This greatly reduces the potential for the installation of one app to break anotherwhat we commonly refer to as DLL Hell.

• Although you would typically deploy an application's required assemblies to the folders under its root folder, you can also share an assembly across all applications by putting it in the Global Assembly Cache.

• .NET provides direct support for object versioning. The framework includes built-in support for ensuring that installing a new version of an object does not break applications that depend on older versions and that you can easily determine which versions of which assemblies an application depends on.

• .NET does away with many silly, obsolete, and problematic C/C++ "features" such as include files, macros, multiple inheritance, mutable/immutable classes, and other language gobbledygook. C#, in particular, is as elegant and powerful as any programming language I have ever used.

• Pointers in .NET are automatically dereferenced, another technique borrowed from Delphi. So, although you get the performance advantage of using a 4-byte pointer to an object rather than, say, storing it in a variant, you have none of the hassles associated with pointers and pointer arithmetic.

• .NET supports a true string type. You concatenate and work with strings as easily in any .NET language as you can in Visual Basic now.

• Every data type in .NET is an object. This also true of Java, but .NET improves on the Java approach in many ways. For example, .NET supports the concept of boxing and unboxinga behind-the-scenes method of achieving the performance benefits of primitive data types without losing the ability to treat them as objects. Another advantage .NET has in this regard is that its base types' virtual method tables are relatively lean because a number of lesser-used methods have been relegated to separate helper classes. In other words, rather than including a method on every base type to translate it to every other base type, .NET has moved most of these routines to separate conversion classes. Each base type carries with it the methods needed to perform common tasks ; lesser-used code is centralized in helper classes.

• .NET assemblies provide extensive meta-data to the outside world. Any class, field, method, property, or event that the code in the assembly exposes to the outside world is available from the binary itself. You do not need source code or symbol files. This is actually how cross-language inheritance works in .NET: You inherit directly from assemblies, not from source code or header files. So, in truth, what you're inheriting from is MSIL, rather than the language with which the assembly was originally built. This meta-data is more extensive than a type library and is inseparable from the assembly. It's stored in binary format and is used for everything from cross-language inheritance to the IntelliSense features of the Visual Studio 7 IDE.

• .NET cleans up the horrendous mess that is modern-day Web development. Instead of having to code an HTML file, then embed VBScript or JavaScript within it, and occasionally reference an ActiveX control or Java applet, you simply design Web forms visually. The code behind the Web form is a class. You don't have to deal with the spaghetti code normally associated with complex Web pages. .NET's Web technologies are known collectively as ASP.NET, a natural evolution of ASP. When you build a Web page in the Visual Studio 7 IDE, you drop the controls you want onto the form, designate where they should reside (server or client), and attach any code you want to their events (e.g., a button's Click event). The code necessary to provide your form's functionality within a browser is generated for you automatically and deployed when you use the Visual Studio 7 IDE to deploy the app to your Web server. (Visual Studio 7 supports the notion of deploying directly to a Web server just as InterDev and Frontpage have for some time.)

• ASP.NET supports data-bound controls and the automatic population of them by data sources. You can use grid controls as well as single-row controls, and can bind them to any data source that .NET supports.

• The code behind ASP.NET Web forms is compiled rather than interpreted. Your ASP.NET apps will execute at native code speed. This is a vast improvement over current ASP technology, which is interpreted and relies heavily on variant data types.

• .NET also supports an evolutionary upgrade to ADO known as ADO.NET. ADO.NET is heavily XML based. In fact, XML is the native file format for ADO.NET data sets. The notion of disconnected data sets is not an afterthought in ADO.NET; it's a core feature. ADO.NET consists of a sensible class hierarchy that resembles the classic ADO framework in some ways and differs from it in others. It provides a scalable, lightweight, connectionless data services layer that was designed from the ground up to be as powerful and easy to use on the Web as it is in desktop applications. By being XML based, ADO.NET provides a ready means of exchanging data with non-.NET applications. It allows the developer to build applications that heavily leverage XML without having to deal with the XML itself any more than absolutely necessary. You code to the class framework, and .NET takes care of the rest.

• .NET's data access is language neutral. It works the same in any .NET language. Unlike classic ADO, in which there's an obvious advantage to using Visual Basic, all .NET languages work equally well with ADO.NET. It uses the same data types as the CLR (they're both based on XML data types) and provides the entirety of its functionality through regular .NET classes.

• ADO.NET supports advanced XML features such as XML transformations and schemas. It supports connecting directly to OLEDB providers such as SQL Server's SQLOLEDB and to XML-based sources. It makes building apps that pull together data from lots of different sources a snap.

• Visual Studio.NET features the most intelligent , most productive software development environment ever created. It has all the basics covered with features like IntelliSense hints while you type, syntax highlighting, and a versatile project manager. It also has a number of advanced features that you don't see often in mainstream development environments. One of my favorites is the code editor. It's probably the best I've seen in a mainstream tool, and sports features like code folding (the ability to collapse code nodes so that they don't display)a great feature when you're focusing on a particular method and want to clear the edit window of distractions. Another nice feature is dynamic help: The IDE watches what you type and displays help from the MSDN Library in an unobtrusive panel on the right of the screen (   la Office XP). Control toolboxes are hidden on the left of the screen. They display when you hover the mouse over them, or you can pin them in place. Web Service and other types of external references can be made right from the IDE. A few clicks of the mouse and the reference is added along with any code necessary to support it. The IDE features a Web-like interface, complete with a start-up page, links to recent projects, and Microsoft developer content on the Web.

No discussion of .NET would be complete without at least a little dabbling in code. Listing 16-1 shows the source to a Hello World application in Visual Basic.NET. Note that I only wrote one line of codethe call to MsgBox() (in bold type). The rest was autogenerated by the IDE. I've left out the autogenerated property settings and form setup code because it's normally not displayed.

Listing 16-1 A simple Visual Basic.NET application.

Public Class Form1 Inherits System.Windows.Forms.Form Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click MsgBox("Hello world!") End Sub End Class

As you can see, Visual Basic now supports object orientation and inheritance. Our form class (Form1) inherits from the base form class in the .NET Framework, System.Windows.Forms.Form. This base form class in actually written in C#, so you're seeing cross-language inheritance in actionsomething COM has never had.

The method Button1_Click() is a method of Form1. Clicking Button1 causes this method to execute and passes in a reference to the control that triggered it via the sender parameter.

Now here's the same app in C# (Listing 16-2):

Listing 16-2 A Hello World app in C#.

using System; using System.Drawing; using System.Collections; using System.ComponentModel; using System.Windows.Forms; using System.Data; namespace HelloWorldCS { /// <summary> /// Summary description for Form1. /// </summary> public class Form1 : System.Windows.Forms.Form { private System.Windows.Forms.Button button1; /// <summary> /// Required designer variable. /// </summary> private System.ComponentModel.Container components; public Form1() { // // Required for Windows Form Designer support // InitializeComponent(); // // TODO: Add any constructor code after // InitializeComponent call // } /// <summary> /// Clean up any resources being used. /// </summary> public override void Dispose() { base.Dispose(); if(components != null) components.Dispose(); } /// <summary> /// The main entry point for the application. /// </summary> [STAThread] static void Main() { Application.Run(new Form1()); } private void button1_Click(object sender,System.EventArgs e) { MessageBox . Show("Hello world!"); } } }

Although there's a bit more code here than there was in the Visual Basic listing, I only wrote one line of it (in bold type). The rest was automatically created. If you're familiar with C and C++, the syntax probably looks very familiar to you. C# does not need or use header filesall definitions are inlinethat is, the implementation also serves as the interface. You decide what is or isn't visible to the outside world via modifiers (e.g., private, public, and so on).