.Net Framework

In the ASP/VB6 model, Microsoft had developers building a component and then calling it via an ASP. Microsoft realized that it would be a good idea to make the component directly callable over HTTP, so that an application anywhere in the world could use that component. Microsoft threw their support behind SOAP, Simple Object Access Protocol, which allows developers to call a component over HTTP using an XML string, with the data returning via HTTP in an XML string. Components sport URLs, making them as easy to access as any other Web item. SOAP has the advantage of having been a cross-industry standard, and not just a Microsoft creation. .NET provides you with integrated debugging tools. If you've ever debugged an ASP application that had VB COM components, you know that you had to use Visual InterDev to debug the ASPs and VB to debug the components. If you also had C++ components in the mix, you had to use the C++ debugger on those components. With .NET, there is one debugger. Any language that targets the .NET Framework can be debugged with that single debugger, even if one part of your application is written in VB.NET and calls another part written in C# (pronounced C-Sharp), or any other language built to target the .NET Framework. The .NET Framework is a collection of services and classes. It exists as a layer between the applications you write and the underlying operating system. This is a powerful concept: The .NET Framework need not be a Windows-only solution. The .NET Framework could be moved to any operating system, meaning your .NET applications could be run on any operating system hosting the .NET Framework. This means that you could achieve true cross-platform capabilities simply by creating VB.NET applications, provided the .NET Framework was available for other platforms. Although this promise of cross-platform capability is a strong selling point to .NET, there has not yet been any official announcement about .NET being moved to other operating systems.

One of the major components of the .NET Framework is the Common Language Runtime, or CLR. The CLR provides a number of benefits to the developer, such as exception handling, security, debugging, and versioning, and these benefits are available to any language built for the CLR. This means that the CLR can host a variety of languages, and can offer a common set of tools across those languages. Microsoft has made VB, C++, and C# premier languages for the CLR, which means that these three languages fully support the CLR. In addition, other vendors have signed up to provide implementations of other languages, such as Perl, Python, and even COBOL. When a compiler compiles for the CLR, this code is said to be managed code. Managed code is simply code that takes advantage of the services offered by the CLR. For the runtime to work with managed code, that code must contain metadata. This metadata is created during the compilation process by compilers targeting the CLR. The metadata is stored with the compiled code and contains information about the types, members, and references in the code. Among other things, the CLR uses this metadata to Locate classes Load classes Generate native code Provide security The runtime also handles object lifetimes. Just as COM/COM+ provided reference counting for objects, the CLR manages references to objects and removes them from memory when all the references are gone, through the process known as garbage collection. Although garbage collection actually gives you slightly less control than you had in VB, you gain some important benefits. For example, your errors should decrease because the number of objects that end up hanging around due to circular references should be reduced or completely eliminated. In addition, garbage collection ends up being much faster than the old way of destroying objects in VB. Instances of objects you create that are managed by the runtime are called managed data. You can interact with both managed and unmanaged data in the same application, although managed data gives you all the benefits of the runtime. The CLR defines a standard type system to be used by all CLR languages. This means that all CLR languages will have the same size integers and longs, and they will all have the same type of string no more worrying about BStrs and CStrs! This standard type system opens up the door for some powerful language interoperability. For example, you can pass a reference of a class from one component to another, even if those components are written in different languages. You also can derive a class in C# from a base class written in VB.NET, or any other combination of languages targeted to the runtime. Don't forget that COM had a set of standard types as well, but they were binary standards. This meant that with COM, you had language interoperability at run time. With .NET's type standard, you have language interoperability at design time. After it is compiled, managed code includes metadata, which contains information about the component itself, and the components used to create the code. The runtime can check to make sure that resources on which you depend are available. The metadata removes the need to store component information in the registry. That means moving a component to a new machine does not require registration, and removing components is as simple as deleting them. As you can see, the Common Language Runtime provides a number of benefits that are not only new, but should enhance the experience of building applications. Other benefits that you will see in more detail include some of the new object-oriented features to ASP.NET. Many of these new features are not so much additions to the language as they are features of the runtime that are simply being exposed to the ASP.NET.