Visual Basic.NET How to Program (PDF)

Appendix G COM Integration 1341
and the differences between its architecture and that of .NET. After reading this appendix,
readers should have a basic understanding of COM and should be able to use COM components
in .NET applications. To learn more about .NET and COM, consult the Web
resources described in Section G.4.
G.4 Internet and World Wide Web Resources
www.microsoft.com/com
The Microsoft COM Web page provides technical white papers, documentation and developer support.
This Web page is an essential resource for COM developers.
www.cs.umd.edu/~pugh/com
This Web site presents a high-level technical overview of the COM architecture.
msdn.microsoft.com/msdnmag/issues/01/08/Interop/Interop.asp
This Web site provides an introduction to integration services provided in .NET. The Web site includes
introductory examples and describes .NETs COM interoperability capabilities.
SUMMARY
Initially, applications created for Windows or DOS were designed as single monolithic executables—entire
applications packaged in single executable files.
As applications grew larger and more complex, it became impractical for developers to construct
and distribute all the necessary components of an application, which resulted in longer development
times and more costly distribution mechanism.
Microsoft incorporated dynamic link libraries (DLL) in Windows to allow developers to modularize
and reuse code.
A shared library, or dynamic link library, is a file containing compiled code that an application
loads at execution time.
Runtime loading allows developers to modify a single library and immediately test the results
without rebuilding the entire application.
Shared libraries increase the modularity of programs by allowing multiple applications to access
a single code library.
The partition of programs into smaller “pieces” makes it easier to distribute application upgrades,
because only those DLLs modified must be redistributed.
Often, developers packaged DLLs with their applications to ensure that users were running the library
version designed for their software. However, the packaged DLLs could overwrite preexisting
libraries on users’ systems, possibly breaking previously installed software.
The problems introduced by shared libraries were so difficult to locate and fix that their effects
became known as “DLL hell.”
In an attempt to combat “DLL hell,” Microsoft developed the Component Object Model (COM).
COM is a specification that controls library versions, backwards compatibility and language interoperability.
The COM specification, defined by Microsoft, is detailed and strict to ensure that COM developers
create compatible libraries.
Microsoft implemented the COM architecture on a large scale. Today, virtually all Windows libraries
adhere to the COM specification.
When implemented correctly, COM ensures highly organized and reusable libraries, but it does
have limitations.