The .NET Strategy
For years, Microsoft has provided to developers a suite named Visual Studio that consists of a visual development environment for various programming languages that Microsoft produces. However, having the languages bundled together hasn’t meant that developers can more easily use something written in another language. The only way in which to accomplish this has been to create a COM object or an ActiveX control. This means that although developers can use anything written in any language as a COM object, they are pretty limited in how that object’s functionality can be extended.
Another major complaint by developers has been the nightmare involving different ver-sions of various DLLs, often referred to as DLL hell. Basically, every new version of a DLL cannot break a previous version’s functionality because one DLL might be refer enced by many different applications, all of which could be expecting the DLL to pro-vide different functionality. This has created a versioning nightmare for the providers of those DLLs.
After many years of this, Microsoft has finally introduced a new version of Visual Studio that promises to ease all these problems for developers. First and foremost is the concept of the Common Language Runtime (CLR). The CLR provides a single set of runtime files for use by every language within Visual Studio. In other words, if you write a Visual Basic
.NET application, your application will use the same runtime libraries as if you had writ-ten the application in C#. This CLR allows for the inheritance of classes across languages. For instance, you can define a class in Visual Basic .NET and inherit from it in a C# application. Quite a nice feature—one that many of us have been requesting for years.
Visual Studio .NET also promises to ease the struggles created by DLL hell by having all DLLs referenced within the application directory. This means you no longer have one global repository for DLLs. Now, every DLL used by an application can be found within the application directory.
Although this may seem like a step back, at first, you have to understand some of the reasoning that went into this decision. Imagine a scenario in which you create an object that uses early binding to bind to various methods of, say, a COM object. What happens is that the early binding uses a pointer to an address for any methods and properties accessed. Once you’re done coding your object, you package and ship it. Then, two years down the road, one or more of your users install an application that uses a newer version of the COM object you referenced for early binding in your object. If the authors of that object weren’t careful, the pointer your object has to the addresses of the proper-ties, events, and methods of the COM object may now be pointing to the wrong property, event, or method, which will cause a major application malfunction. If, instead, your object were to have a local copy of that same object, you wouldn’t have to worry about that scenario unless someone specifically copied over the file.
Another interesting major feature of Visual Studio .NET is the framework included within it. Until now, VB developers really haven’t been able to take advantage of classes in the Microsoft Foundation Classes (MFC) the way in which C++ developers have been able to. Although the Visual Studio .NET Framework is not the MFC, it does provide something that Visual Basic developers have never really had: a complete application framework. In fact, a concept that will be new to many Visual Basic developers is inheri-tance. The inheritance that existed in previous versions of Visual Basic was not really inheritance at all. Basically, VB developers were limited to defining a class and then cre-ating instances of that class within their applications. Now, VB developers can take advantage of the full power of inheritance by defining a class and then defining another class based on that new class, and another subclass based on that class, and so on.
Another major complaint that developers have had in the past is that, until now, they could not create an Internet application using object-oriented programming because the Internet was still basically reduced to a series of string concatenations to generate output to the browser. Now, Microsoft has bridged that gap. The same programming you have done in the past for Windows applications can be used, with slight modifications, to develop Web-based applications. In fact, Microsoft has made the creation of Web Services even easier than before. By having the IDE really do all the extra work in registering the Web service, developers are now able to concentrate on providing the functionality rather than on how they expose that functionality as a Web Service. Microsoft has also invested a considerable amount of time and energy in making it simpler for you to take advantage of Web Services. With the new IDE, you can simply add a reference to a Web Service to your application and gain all the benefits of that service, just as if it were another class within your application—you no longer have to worry about the necessary SOAP calls to that Web service. Visual Studio .NET figures out those little details for you. All you have to do is make a call to the Web Service, just as if it were another resource residing on the local machine, pass in the necessary parameters, and store the results.
All in all, Visual Studio .NET promises to open up the door to a whole new level of application design and functionality.