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.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.