The .NET Platform
Development Tools
COM & COM+
Data Access
Web Development
XML Technologies
Windows Servers
Wireless & Mobile
Security issues
Design & Process
Career Development
Analysis & Comment
Disposable Objects
We found this book useful!
You are not logged in: login here to access all areas.
Understanding the .NET Framework
What does Microsoft's .NET strategy mean for the software developer? Matt Nicholson explains.
Author: Matt Nicholson
Last updated: Dec 2001
The .NET Framework Classes and Forms Web Services Visual Studio.NET Visual Studio.NET will be available in three versions. The best way to obtain these is by joining the Microsoft Developer Network (MSDN) programme. This will ensure you are one of the first to receive the release version, and are kept up to date with all upgrades: Visual Studio.NET Professional will be included in MSDN Professional; Visual Studio.NET Enterprise Developer will be included in MSDN Enterprise; Visual Studio.NET Enterprise Architect will be included in MSDN Universal. For further details, see www.microsoft.com/uk/msdn/about/. Alternatively, all three editions will be available off-the-shelf, or under Microsoft?s volume licensing schemes, and there will also be an Academic edition.
The job that the professional software developer is called upon to do has changed dramatically over the past few years, largely as a result of changes in the way business is conducted. The public face of an increasing number of companies is now the Internet, where customers expect to interact directly with the company?s internal systems, with obvious implications for security and scalability. Such solutions must be constructed in ?Internet time?, and yet remain flexible and open to expansion.
Applications can no longer assume they are talking to conventional desktop PCs. Instead users expect to connect up using a handheld device, perhaps over a wireless connection, or even a mobile phone.
Modern applications are distributed, and not necessarily across high-speed ?always on? networks. Components may only be available though intermittent links across the Internet. Furthermore, applications increasingly have to link to so-called ?legacy? systems running on disparate and often incompatible platforms.
This means a move away from tightly coupled modules towards more loosely coupled, component-based systems. Protocols like DCOM become less appropriate because they cannot cross firewalls in a secure fashion. Instead components expose methods across the Internet using XML-based protocols such as SOAP, WSDL and UDDI.
Like the other players in this market, Microsoft has already extended its toolset to allow for this new world. The Microsoft SOAP Toolkit and the UDDI SDK let Visual Basic 6.0 users construct and use Web services. The eMbedded Visual Tools allow Visual Basic and Visual C++ 6.0 developers to target Windows CE devices.
However, useful as these tools are, the underlying architecture is still COM, while Visual Studio 6.0 continues to present a range of disparate programming models. Therefore, sometime in the mid to late 1990s, Microsoft bit the bullet and started work on a completely new development platform, designed from the ground up for the construction of component-based, distributed applications that could be delivered across the Internet to a wide range of devices. The result was the .NET platform, unveiled in detail at Microsoft?s Professional Developers Conference (PDC) last year.
At first sight the .NET platform offers a very different approach to the construction of applications. However, many of the underlying concepts should be familiar, and it is ultimately far more straightforward. As always the foundation is the operating system, which can be any current version of Windows. The .NET platform will support other devices as they become available, and Microsoft has submitted key components to the ECMA which will allow development of compatible platforms for UNIX.
The core of .NET is the .NET Framework, and at the heart of the .NET Framework is the Common Language Runtime (CLR). Under .NET, source code is not compiled directly to machine code, but instead to an intermediate language commonly referred to as IL. It is the CLR that activates objects, performs security checks, verifies type safety and allocates memory. It also manages memory through an extremely efficient garbage collector. Code written for the CLR is referred to as ?managed? code.
While there are obvious parallels with the Java Virtual Machine (JVM), there are also fundamental differences. For a start, the CLR is largely language independent. Microsoft itself is supporting Visual Basic, Visual C++, JScript and a new language called C#, as part of Visual Studio.NET. It will also support the Java syntax through Visual J# (formerly JUMP to .NET). Other companies are providing .NET versions of APL, COBOL, Eiffel, Fortran, Pascal, Perl, Python, RPG and Smalltalk, to name but a few.
IL operates at a similar level to Java bytecode, but is more compact and flexible. For example, although deemed ?unsafe? and so ?unmanaged?, the CLR is happy to work with pointers and other trappings of traditional C++ code, while giving C++ developers access to the .NET Framework through Managed Extensions to the language.
IL is optimised specifically for compilation into machine code by the CLR using a highly efficient JIT (Just In Time) compiler. Once a method has been compiled to machine code it remains in memory. Alternatively, you can arrange for the IL to be compiled when the application is installed, in which case it resides on the machine as machine code.
One side effect is that all managed code runs at the same speed, regardless of the originating language. Visual Basic is no longer inherently slower than C++.
One area where .NET developers really benefit over the COM world is in deployment. The IL is contained in Portable Executable (PE) format, just like any Windows executable or DLL. However, under .NET this format includes metadata that replaces the type libraries of COM. Components become self-describing, and deployment simply means copying the files that make up the component (called the ?assembly?) to a directory on the target machine. There is no need to register them in the Windows registry. Furthermore, multiple versions of a component can run side by side, so ending ?DLL hell?.
The .NET Framework itself will be included in Windows .NET Server (the server version of Windows XP). In the meantime, installation routines can automatically install or update the runtime on target machines, and the runtime is likely to be available for download in its own right.
Despite the wide range of programming languages supported by the .NET Framework, all conform to a common object-oriented programming model. If you know how to do something in one language, you know how to do it in all the languages. Indeed the biggest task facing Windows developers is not learning a new incarnation of their chosen language, but rather learning about the .NET Framework.
The object model supports single inheritance of classes, polymorphism, and multiple inheritance of interfaces. Classes can support properties, methods and events. Furthermore, because the model is implemented by the CLR, classes written in one language can inherit from classes written in another, take advantage of polymorphism, and catch exceptions thrown by objects written in another language.
Another major feature is the Common Type System (CTS) which supplies all the supported languages with a uniform and rich set of types. Reference types are pointers to heap-based objects, and include classes, interfaces, strings and arrays. However this is not an efficient way of handling intrinsic types, structures or enumerations where the amount of memory required by the data is relatively small. Therefore the CLR also supports value types which are allocated on the stack and passed by value.
That said, every type in .NET ultimately derives from a single base class, even if it?s an integer, a char or a boolean. An Integer in Visual Basic.NET is actually an alias for the System.Int32 class in the .NET Framework, which is derived from the System.ValueType class. One major innovation is a process called ?boxing? which occurs when a value type is assigned to an object variable. Conversion back to a value type is called ?unboxing?.
The .NET Framework provides you with one of the largest class libraries ever built, containing more than 5,000 classes. These are divided into a coherent set of over 90 namespaces, all part of the System namespace. Third parties can add their own namespaces, as indeed Microsoft has done with, for example, the Microsoft.VisualBasic namespace. This gives you access to the IL compiler for VB.NET, plus a set of classes that provide a managed implementation of many of the features found in VB6 that have no direct parallel in the .NET Framework.
At the lower level are namespaces such as System.Configuration, for writing installation routines and configuring assemblies; System.Diagnostics, for debugging applications, accessing event logs and so forth; and System.Security which provides cryptography services and implements X.509 certification. There is full support for free threading, accessed through the System.Threads namespace, while the System.Reflection namespace gives you access to information about assemblies, modules and types.
Another powerful namespace is System.Attribute, which provides support for attribute-based programming. Similar to pragmas in C++, attributes are statements that act as instructions to the compiler. A particularly powerful example is the WebMethod attribute which signals to the compiler that a method should be exposed as a Web service, with all that involves (see below). You can even implement attributes of your own.
Data access is supported by the System.Data namespace which implements ADO.NET and gives access to a wide range of data sources, with good support for sources that can be offline, and so requiring synchronisation. This namespace is complemented by System.Xml which supplies classes for handling XML documents and includes support for standards such as XML Schema, XPath and XSLT.
An important part of the .NET Framework is the COM Interop layer which lets you create proxies that fool .NET clients into treating COM objects as .NET objects, and vice versa. Using this, Microsoft has exposed COM+ Services as a set of .NET classes, mostly in the System.EnterpriseServices namespace. It is here you will find support for JIT activation, synchronisation, object pooling, shared properties and transactions.
Client-level classes divide neatly into two principal namespaces. On the one hand, System.Windows.Forms provides all you need to create traditional Windows applications, including Multiple Document Interface (MDI). One happy side effect is that Visual Basic developers can now inherit from forms. Visual Basic developers can also make use of the GDI+ facilities exposed in the System.Drawing namespace to create high-performance 2D and 3D graphics.
On the other hand is the System.Web namespace which replaces ASP (Active Service Page) technology with ASP.NET. This is where you create Web Forms and Web Controls that the CLR can render into HTML. This is also where you build Web Services.
Like all great ideas, the concept is very straightforward. A Web Service is simply a software component whose methods are accessed using messages written in XML and transported by standard Internet protocols such as HTTP or SMTP. The key protocols behind Web services were developed by Microsoft and IBM, together with DevelopMentor and Userland, and all companies involved have been at pains to ensure these are managed by neutral standards bodies (usually the W3C).
Web services have the potential to transform the way we do business. Delivery companies could expose their schedules and price lists through Web services, which means your application would be able to automatically select and book the most efficient delivery option. A travel agent could call upon the Web services exposed by airlines, hotels and so forth to present you with the widest selection of options, and allow you to book the holiday of your choice on line.
There are many issues to resolve before Web services become commonplace. However, Web services are built into the .NET infrastructure from the ground up, which gives Microsoft an immediate advantage over its main competitor, namely Java 2 Enterprise Edition (J2EE).
For Web services to work as a business model, those who host services need to know who is making use of them, which requires a reliable and secure mechanism for authentication. Microsoft?s intention is for this to be provided by its Passport service, the next version of which will be based on Kerberos certification. Windows .NET Server will allow Passport federation down to an Active Directory server, so that logging on to the network will also log you into Passport.
Building on this, Microsoft is planning a range of Web services called .NET My Services (previously codenamed Hailstorm) which will allow users to store personal information out on the Internet, rather than on local machines. This brings obvious benefits, such as the ability to walk into an Internet café and instantly access your address book, diary and personal documents. With your permission, a delivery company could query your .NET Calendar service to find out when you are in, and then use your .NET Alerts service to notify you when you can expect delivery. The initiative puts a big onus on Microsoft to maintain privacy and security, but if successful it will open up countless opportunities for the software developer.
You do not need VS.NET to write .NET applications as the .NET Framework SDK comes with the IL compilers for VB.NET, C#, JScript and the C++ Managed Extensions, and a host of utilities to aid in debugging. However, as you would expect, the next version of Visual Studio is designed specifically for the .NET Framework, and includes the SDK.
As you might also expect, this means some major changes. For example, there is a single development environment for all languages - one code window, one debugging window, one control toolbox, and so forth. The Windows Forms designer will be relatively familiar to VB developers, but this is matched by a Web Forms designer that is equally intuitive. The code window features Intellisense and auto completion on all languages, but in VS.NET this extends to data table, index and field names. There are new wizards and graphical tools for working with data sources, and with XML and XML Schema.
It will come as no surprise to find Web services very strongly supported in VS.NET. There are tools for discovering Web services through UDDI, and for registering your own services with a UDDI server. This includes automatic generation of WSDL files, necessary for others to know what your services do and how to use them. Microsoft has even made arrangements with a handful of Internet Service Providers so that you can test your Web services in the field.
Three languages are absent from VS.NET, namely Visual J++, Visual FoxPro and VBScript. Legal battles with Sun Microsystems have caused some confusion in the Java arena, however Visual J# will give full support for Visual J++ and source code written for Java Development Kit (JDK) 1.1.4, although its release is not scheduled until sometime after VS.NET itself. Open a Visual J++ project and VS.NET will do its best to convert the source code to Visual J#, and map Microsoft extensions such as JavaCOM and JDirect to the appropriate namespaces. Alternatively, you will be able to convert such code to C#.
There is a new version 7.0 of Visual FoxPro, but this will not be part of VS.NET. VBScript has effectively been replaced by VB.NET for server-side scripting, and Microsoft will be supplying a conversion layer. Visual InterDev has been rendered redundant by the support for Web Forms and JScript in VS.NET.
VS.NET comes with a new version of Visual C++ that is fully compatible with version 6.0, although significantly enhanced. It includes support for Managed Extensions which allow you to write C++ programs that run under the CLR. However the most likely migration path for C++ developers is to C# which offers a familiar syntax while fully exploiting the .NET Framework.
In addition to the Professional edition, there will be two Enterprise editions of VS.NET, one aimed at developers and the other at software architects. Visual Studio.NET Enterprise Developer will include Developer Editions of Windows 2000 Server and a number of .NET Enterprise Servers, together with Visual SourceSafe, a number of database modelling tools, Visual Studio Analyzer, and Application Center Test (ACT) for stress-testing Web applications.
Visual Studio.NET Enterprise Architect adds tools for conceptual and logical modelling, based on Microsoft?s Visio drawing package, together with a Developer Edition of BizTalk Server. It will also support the creation of Enterprise Frameworks and Templates. These let the architect put together an initial project structure, define the components available for use within the organisation, and establish policies for their use. Templates and policies are defined in an XML-based language, and can be enforced within the Visual Studio environment, or simply used as guidance.
While it probably does not make sense to migrate your existing applications to .NET, anyone involved in software development for the Windows platform needs to get up to speed with the .NET Framework, Visual Studio.NET, and the .NET language of their choice, as soon as possible.
With .NET, Microsoft has once again re-invented what it means to be a Windows software developer. However, as industry guru David Chappell puts it, ?If you don?t like change, get out of the software business.?
Standard editions of Visual Basic.NET, Visual C++ and Visual C# will be available separately off-the-shelf, but these will lack some of the tools supplied in the full Visual Studio package. Visual J# will be available separately as well, when it is released sometime around the middle of 2002.
Click here for our Privacy Statement. Copyright © Matt Publishing. All rights reserved. No part of this site may be reproduced without the prior consent of the copyright holder.
