Examining Visual Studio .NET

For building new web and Windows applications, VS.NET claims improved developer productivity, better code reusability, and excellent support for XML web services. According to reports, it's not uncommon for early adopters to double their overall productivity with VS.NET, compared to VS 6 and similar tools. For certain tasks, such as programming, debugging, and deploying complicated web pages, the productivity boost is supposedly much greater than a factor of two.

New Technologies

The cornerstones of VS.NET involve new technologies. At the heart is the .NET Framework — a set of Windows features that is built around a Common Language Runtime (CLR), on top of which are layered class libraries for building Windows-style applications (Windows forms), web-style applications (ASP.NET), and XML web services. All .NET languages are compiled to Microsoft Intermediate Language (MSIL) prior to deployment, and converted to native code by a .NET Framework just-in-time (JIT) compiler.

CLR and MSIL let all .NET languages play together. For instance, think about using a C# class, which in turn inherits from a C++/ATL COM object, which traps an exception thrown by a Visual Basic .NET (VB.NET) program. And because the platform supports this kind of multilanguage integration, the VS.NET IDE can, for instance, debug across the three languages within a single IDE.

The JIT compiler offers additional security and safety at run time, and the possibility of portability. (Microsoft says it will take the standardized subset of the .NET Framework — called the "common language infrastructure" — and build an implementation on FreeBSD.) If the JIT compiler for intermediate language code reminds you of Java, welcome to the club. But before you get upset about that, consider that Microsoft has quietly been using intermediate language code in Visual Basic and most of its applications (including Office) for many years.

C#, a language based largely on C++ with more than a passing resemblance to Java, is included in VS.NET as Visual C#.NET. Likewise, the familiar Visual C++ is packaged in VS.NET as Visual C++.NET and includes traditional C++ stuff for standalone use, plus extensions for use with the .NET Framework. For its part, VB.NET is an enhanced and somewhat incompatible dialect of Visual Basic. (For more information on VB.NET, see "Examining VB.NET," by Lauren Hightower, DDJ, March 2002.) Still, it seems the incompatibilities are more than justified by the new capabilities, but then again I haven't been trying to migrate much old Visual Basic code.

The Windows forms classes in the .NET Framework are, according to Microsoft, "the new platform for Microsoft Windows application development." Windows forms are both inheritable classes and controls. A variety of .NET controls are included for use in Windows forms, and it's straightforward to bind data to Windows forms controls. Using the new GDI+, you can create graphics, draw text, and manipulate graphical images as objects on Windows forms. Windows forms, however, require the .NET Framework to be running on the client computer.

ASP.NET web forms are the new model for building web pages; ASP.NET is the web application environment in the .NET Framework. An ASP.NET web forms page separates the visual component (the ASPX page) from the logic (the code-behind), and can automatically render different HTML depending on what browser or mobile device is viewing the page. VS.NET includes a web forms designer with both grid and flow layout modes, along with a variety of controls.

The big difference from Windows forms is that the .NET controls on an ASP.NET web form page run on the server, not the client. This is good because the client can be running any web browser and doesn't need the .NET Framework. It's bad because server-side programming means lots of roundtrips to the server over the Internet. This isn't a big problem, however, if you have a broadband connection and low ping times between your client and server (of course, this is true of JSP, PHP, and the like, too).

The ASP.NET web forms model is powerful, especially since it's so much like Windows forms and traditional Windows programming, plus it gives you true RAD and OOP programming tools for web development.

You can run ASP.NET and ASP side-by-side, but there are issues if you try to pass state from one to the other. Moreover, there is no easy or automatic way to upgrade existing ASP applications to ASP.NET, although the migration can be done by hand with some thought.

Clearly, XML web services are the most hyped part of Microsoft .NET. But forget the hype for a minute: XML web services are really applications that can receive and respond to requests and data using XML (although HTTP isn't required) via the SOAP protocol. Because the .NET Framework has built support for XML web services into the platform through technologies such as ASP.NET, it's straightforward to build or consume a simple XML web service using VS.NET — you need only use a web service attribute on a method to invoke the underlying .NET Framework infrastructure. There are two big reasons to build web services: to make it easy to reuse your application, and to interoperate with nonMicrosoft platforms.

To illustrate, I've included an XML web service (available electronically; see "Resource Center," page 5) that returns the string "Hello, World from DDJ"; see Example 1(a). When the button on the web form is pressed, it calls the web service, and displays the returned string in Label1; see Examples 1(b) and 1(c).

C#

C# is a simplified, component-oriented offshoot of C++, with a few ideas added from other languages. In C#, everything really is an object: Even primitive types like int can be boxed into the root object class. In C#, there is no multiple class inheritance; instead, there is a multiple interface mechanism. C# has a new operator, but no delete operator: The .NET Framework has built-in garbage collection, which extends to all programming languages on the .NET Framework.

For most of the things for which C programmers use pointers, C# has references, denoted by the dot notation, which are managed by the .NET Framework garbage collector. For those special cases where pointers are absolutely necessary, C# has unsafe code. Within a code block marked unsafe, objects are protected from the garbage collector, and traditional C/C++ pointers are allowed.

For several reasons, C# is my primary language for .NET projects.

• C# is the native language of .NET, making it well documented when it comes to using the CLR.
• C# combines the power and concise notation of C++ with the ease of development of Visual Basic.

• C# has a really cool mechanism for generating documentation using /// comments that hasn't made it into the other .NET languages yet. Visual C#'s ability to display those comments as pop-ups helps support my first point.

• C# comes easy. It's so similar to C++, Java, and JavaScript, and the IDE is so helpful, that I seem to naturally write correct C# code most of the time. I've written a lot of C++, Java, and JavaScript, and when I do get confused and start writing constructs from those languages that aren't exactly the same as C#, the VS.NET IDE underlines the problems for me in much the same way as Microsoft Word underlines misspelled words and grammar errors.

Visual Basic .NET

Visual Basic .NET had to become object oriented to make it into .NET. The OOP features added were inheritance, interfaces, and overloading. VB.NET also got structured exception handling, custom attributes, delegates, multithreading, and three new data types to give it full compliance with the .NET Framework's Common Language Specification (CLS).

It isn't hard for Visual Basic programmers to learn VB.NET. The crux of the effort is to learn object-oriented programming and design, and understand multithreading; the actual syntax changes to the language are trivial. On the other hand, rewriting large amounts of existing VB code could be really annoying.

The VS.NET's Professional Edition (and above) includes an upgrade wizard that sort of, kind of, works, but you should expect to have to deal with quite a few upgrade issues, warnings, and notes after it runs. I had highly mixed results with it. If you have a large investment in Visual Basic code, be cautious about upgrading, and do not uninstall your existing copy of Visual Basic 6.

Other Languages

Managed extensions for C++ are language extensions to C++ for writing .NET Framework applications. They let you mix traditional unmanaged and managed C++ code within the same application. The advantage of managed C++ is that you can wrap existing components as .NET Framework components, letting you bring existing code into the .NET Framework. The managed C++ layer is fairly thin, with a low overhead at run time.

JScript.NET is an upgrade to JScript based on ECMAScript Edition 4, plus compiled code, cross-language support through the CLS, and access to the .NET Framework. JScript.NET is mostly intended for use with ASP.NET and application scripting. The six upgrades to JScript.NET are support for .NET classes, optional strongly typed variables, conditional compilation, .NET namespaces, and the const and enum statements.

J# is a variant of Java that compiles to MSIL rather than Java bytecode. (At this writing, J# is only available in a beta version that isn't compatible with the final bits of VS.NET.) J# includes tools to help you convert third-party Java classes to run with .NET.

Many third-party languages work with the .NET Framework, and in many cases integrate with VS.NET. I've used several, including ActiveState's Visual Perl, Visual Python, and Visual XSLT, all of which integrate at the tool level, and ETH's Active Oberon, which doesn't. I haven't tried others, although the idea of mixing Smalltalk, APL, Eiffel, Scheme, RPG, Fortran, and Cobol into one application kind of blows my mind.

.NET Framework

In general, the .NET Framework Common Language Runtime and classes are complete and well designed. It takes time to learn them, but it isn't hard — there's just a lot to absorb. From my experience, programming with the .NET Framework is a lot easier than programming with any of the previous C++ APIs from Microsoft, including the Win32 API, MFC, and ATL. Of course, programming with the .NET Framework may not be as easy as with VB 6, but using the new classes means you'll probably never need to call Win32 API functions to accomplish low-level system functions, and you'll be able to do things you never could before.

Furthermore, the .NET Framework seems better throughout than the Java Class Libraries — and I like the Java Class Libraries. More to the point, the first release of the .NET Framework seems better designed and implemented than the more mature Java 2 SDK 1.3 (including its Standard, Micro, and Server editions). Of course, the .NET Framework doesn't have to be portable to multiple architectures like the Java 2 SDK, and the .NET designers were able to learn from both the strengths and the weaknesses of the Java Class Libraries.

Application Domains and Assemblies

The .NET Framework execution model expands on the old Win32 model of an isolated application process with its own address space and multiple threads of execution. The application isolation provided by a separate address space has been supplanted by the .NET Framework's managed code verification process. In the new model, multiple application domains can run in a single process for lower total overhead without sacrificing security. This can make an improvement in server scalability, and improve performance over architectures that used multiple interacting processes, even on workstations.

According to Microsoft's documentation:

Application domains, which are represented by AppDomain objects, provide isolation, unloading, and security boundaries for executing managed code.

Multiple application domains can run in a single process; however, there is not a one-to-one correlation between application domains and threads. Several threads can belong to a single application domain, and while a given thread is not confined to a single application domain, at any given time, a thread executes in a single application domain.

One of the more annoying problems I faced in a decade of developing and deploying Win32-based programs is commonly known as "DLL Hell." Essentially, I ship a program that installs and relies on a certain number of DLLs, which are global to the system. At some later date, another program installs a DLL that replaces one of mine and introduces an incompatibility with my code. End result: Users scream that my program broke "for no reason."

The .NET Framework fixes the DLL Hell problem by introducing the notion of an application assembly. As the documentation states:

Assemblies are the building blocks of .NET Framework applications; they form the fundamental unit of deployment, version control, reuse, activation scoping, and security permissions. An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality. An assembly provides the common language runtime with the information it needs to be aware of type implementations. To the runtime, a type does not exist outside the context of an assembly.

The assembly includes a manifest that lists all of its components and their versions. The components are typically kept in the application's local directory tree and not installed in the Windows System directory. Not only does that fix the DLL Hell problem, it makes installing a new application a matter of simply copying the directory tree. This new assembly model also supports side-by-side execution: If you design your code for it, the CLR can run multiple versions of your assembly on the same computer, and possibly even in the same process, at the same time, without interfering with each other.

Productivity Gains

When developing web and Windows applications, Microsoft claims you can expect productivity gains by using the .NET Framework and VS.NET when compared to previous Microsoft tools. How come? There are multiple reasons, including that the .NET Framework does more and goes deeper than previous Microsoft APIs. Another is that the VS.NET environment is efficient and helpful — everything that should be done visually, is, and everything that can be done to help you generate correct code quickly, is. Another reason is that the model effectively separates the visual appearance of both web and Windows applications from the code, which lets teams collaborate better without interfering with each other. A final consideration is that code and form reuse is improved in the .NET Framework.

Again, the .NET Framework's Windows forms are both inheritable classes and controls, and both attributes contribute to reuse. ASP.NET web forms are inheritable classes, and can use both HTML controls and web controls, which are themselves inheritable classes. It's not unusual to subclass something like the data grid to add specialized functionality quickly. Of course, C# classes can be inherited, but so can VB.NET classes. Even better, you can inherit classes freely across .NET languages.

Finally, the most powerful and global reuse mechanism is the XML web service. Not only can you reuse a .NET web service, you can consume it from a web page or from Java, Perl, or any other language with SOAP support.

DDJ