Visual Basic .NET: A New Framework
One of the most common questions today is, “Why should I move to .NET?” .NET is new, and there are many questions about what it can do for you. From a Visual Basic standpoint, it's important to understand some of the dramatic benefits that can be achieved by moving to Visual Basic .NET.
Many people have looked at VB .NET and grumbled about the changes. In fact, one industry trade publication contained an article in which several long-time Visual Basic developers complained that the changes were too much and that they felt blindsided. After all, there are significant changes to the language: a new error handling structure (which is optional), namespaces, true inheritance, true multithreading, and many others. Some see these changes as merely a way that Microsoft can place a check mark next to a certain feature and be able to say, “Yeah, we do that.”
Most developers, however, feel there are good reasons for the changes in VB .NET. The world of applications is changing, continuing the evolution that has been occurring over the past several years. If you went back to 1991 and showed a Visual Basic 1.0 developer an n-tier application with an Active Server Pages (ASP) front end, a VB COM component middle tier complete with Microsoft Transaction Server, and a SQL Server back end full of stored procedures, it would look quite alien to him. Yet, over the past few years, the vast majority of developers have been using Visual Basic to create COM components, and they have become quite versed in ADO for their database access. The needs for reusability and centralization (a way to avoid distributing components to the desktop) have driven this move to the n-tier model.
The next logical step in the evolution of n-tier systems was to have a Web-enabled application. Unfortunately, the move to the Web revealed some problems. Scalability was an issue, but more complex applications had other requirements, such as transactions that spanned multiple components, multiple databases, or both. To address these issues, Microsoft created Microsoft Transaction Server (MTS) and COM+ Component Services. MTS (in Windows NT 4) and Component Services (an updated MTS in Windows 2000) acted as an object-hosting environment, allowing you to gain scalability and distributed transactions with relative ease. However, VB components could not take full advantage of all that Component Services had to offer, such as object pooling, because VB did not support true multithreading.
Opening Up on the Web
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 its support behind the Simple Object Access Protocol, or SOAP, which allows developers to call a component over HTTP using an XML string. The data is then returned via HTTP in an XML string. Components exposed via SOAP 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. This has given rise to a number of vendors, including Microsoft's archrivals, lauding the benefits of Web services.
At this point, you might be tempted to think that SOAP is all you need, and that you can just stick with VB6. Therefore, it is important to understand what VB .NET gives you, and why it probably makes sense for you, and many other developers, to upgrade to .NET. For example, you create components and want them to be callable via SOAP, but how do you let people know that those components exist? .NET includes a discovery mechanism that allows you to find components that are available to you. You'll find out more about this mechanism, including the “disco” file, in Chapter 9, “Building Web Services with VB .NET.” .NET also provides many other features, such as garbage collection for freeing up resources, true inheritance for the first time, debugging that works across languages and against running applications, and the ability to create Windows services and console applications.
What Does the “.NET” Mean?
Before proceeding, it's important to understand a little bit more about what is meant by .NET. There are many .NETs here. There is VB .NET, which is the new version of Visual Basic. There is Visual Studio .NET (an integrated development environment that hosts VB .NET), C# (pronounced “C sharp”), and C++.NET. Microsoft is even calling most of its server product “.NET Servers” now. Underlying all this is the . NET Framework and its core execution engine, the Common Language Runtime.
In the .NET model, you write applications that target the .NET Framework. This gives them automatic access to such benefits as garbage collection (which destroys objects and reclaims memory for you), debugging, security services, inheritance, and more. When you compile the code from any language that supports the .NET Framework, it compiles into something called MSIL, or Microsoft Intermediate Language. This MSIL file is binary, but it is not machine code; instead, it is a format that is platform independent and can be placed on any machine running the .NET Framework. Within the .NET Framework is a compiler called the Just-In-Time, or JIT, compiler. It compiles the MSIL down to machine code specific to that hardware and operating system.
In looking at the fundamental changes, it's important to understand that the number-one feature request from Visual Basic developers, for years, has been inheritance. VB has had interface inheritance since VB4, but developers wanted real or implementation inheritance. Why? What are the benefits? The main benefit of inheritance is the ability to create applications more quickly. This is an extension of the promise of component design and reusability. With implementation inheritance, you build a base class and can inherit from it, using it as the basis for new classes. For example, you could create a Vehicle class that provides basic functionality that could be inherited in both a Bicycle class and a Car class. The important point here is that Bicycle and Car inherit the functionality, or the actual code, from the Vehicle class. In VB4 and higher, the best you could do was inherit the structure, minus any implementation code. In VB .NET, the functionality in that base class is available to your other classes as is, or you can extend and modify it as necessary.
.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#, or any other language built to target the .NET Framework.
.NET supplies a standard security mechanism, available to all parts of your application. .NET provides a possible solution to DLL Hell, and removes much of the complexity of dealing with COM and the registry. .NET allows you to run components locally, without requiring the calling application to go to the registry to find components.
There are also things that VB .NET can do that you cannot do today in VB. For example, Web Applications are a new form of project. Gone is Visual InterDev with its interpreted VBScript code. Instead, you now build your ASP.NET pages with VB .NET (or C# or C++.NET), and they are truly compiled for better performance. VB .NET lets you create Windows services natively for the first time by providing a Windows Services project type. And yes, VB .NET lets VB developers build truly multithreaded components and applications for the first time.
Finally, you need to realize that the new language is actually going to have a version number on it, although the final name is undecided. It might well be called VB .NET 2002. This implies that at some point, there will be new versions of VB .NET, just as there were new versions of VB. In this book, references to previous versions of VB will be either VB or VB6. References to VB .NET 2002 will be just VB .NET.
You have decided you need to move from VB6 to VB .NET, and you picked up this book to find out about the changes. Yet, the first thing you see is a chapter about the .NET Framework. Why start with the .NET Framework? The truth is that you cannot understand VB .NET until you understand the .NET Framework. You see, the .NET Framework and VB .NET are tightly intertwined; many of the services you will build into your applications are actually provided by the .NET Framework and are merely called into action by your application.
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 an official announcement about .NET being moved to other operating systems.
In addition, the .NET Framework is exciting because it encapsulates much of the basic functionality that used to have to be built into various programming languages. The .NET Framework has the code that makes Windows Forms work, so any language can use the built-in code in order to create and use standard Windows forms. In addition, Web Forms are part of the Framework, so any .NET language could be used to create Web Applications. Additionally, this means that various programming elements will be the same across all languages; a Long data type will be the same size in all .NET languages. This is even more important when it comes to strings and arrays. No longer will you have to worry about whether or not a string is a BStr or a CStr before you pass it to a component written in another language, which has been a common concern for VB developers calling C-based Windows APIs.