Why Should You Move to Visual Basic.NET?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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 VB.NET.
Many people have looked at VB.NET and grumbled about the changes. There are dramatic changes to the language: a new error-handling structure, namespaces, true inheritance, free threading, and many others. Some see these changes as merely a way that Microsoft can place check marks next to certain features and be able to say, "Yeah, we do that." However, there are good reasons for the changes in VB.NET.
The world of applications is changing. This is merely a continuation of what has occurred over the past several years. If you took a Visual Basic 1.0 developer and showed him an n-tier application with an ASP front end, a VB COM component middle tier, 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 as well. 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 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 Services (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 free threading.
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 SOAP, Simple Object Access Protocol, which allowed developers to call a component over HTTP using an XML string, and the data was returned via HTTP in an XML string. Components sport URLs, making them as easy to access as any other Web item. SOAP had the advantage of having been a cross-industry standard, not just a Microsoft creation.
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 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. .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.
Before proceeding, it's important to understand a little bit more about what is meant by .NET. There are a number of .NETs here. There is VB.NET, which is the new version of Visual Basic. There is Visual Studio.NET, which is an integrated development environment that hosts VB.NET, C#, and C++.NET. Underlying all these is the .NET Framework, built atop the Common Language Runtime.
In the .NET model, you write applications that target the .NET Framework. That gives the application automatic access to such benefits as garbage collection, 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 file 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 for that hardware and operating system.
In looking at the basics, it's important to understand that the number-one feature request for Visual Basic, 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 functionality in that base class is available to you 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# (pronounced "C-Sharp"), or any other language supported in 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.
Other than mentioning inheritance, I haven't even touched on things the VB.NET can do that you cannot do today in VB. For example, Web Applications is a new feature. Gone are Visual InterDev and interpreted VBScript code. Instead, you now build your ASP.NET pages with VB.NET (or C# or C++), 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 free-threaded components and applications for the first time.
Finally, you need to realize that the new language is actually called VB.NET 7.0. This implies that, at some point, there will be a VB.NET 8.0, and so on. In this book, references to previous versions of VB will be either VB or VB6. References to VB.NET 7.0 will just be VB.NET.
You have decided that you need to move from Visual Basic 6 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 that 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.