Hour 21. COM with .NET
The computer industry is probably one of the fastest moving industries in existence today. How many times have you heard people complain that the hardware they just bought will be obsolete in a short amount of time? Not only does this liquidity apply to hardware sales but also to software development. Software development is constantly changing to keep up with the latest breakthroughs in programming. The latest and greatest software you just purchased is soon replaced by a new and better version in less than a year. The component your company purchased from a third-party vendor is soon replaced by a component with greater flexibility and newer features.
The Component Object Model (COM) was a breakthrough programming model. Finally there was a technology in which software could literally be built using a variety of reusable components. It also broke the barrier that existed between differing programming languages by allowing code written in one language to be used by another language. By applying a standard consisting of strict programming rules and certain design guidelines, any programming languages adhering to these rules could be used together in a seamless programming environment. However, with every advantage there is always a disadvantage. So, what was the disadvantage of using COM?
Simply put, COM was just too difficult to use for the average programmer. Sure, using components or ActiveX controls within Visual Basic was a somewhat trivial matter. However, take a group of programmers and ask how many can implement connection points within ATL or explain the differences between aggregation and containment, and you would see very few hands raised.
One of the design tenants of the .NET Framework is to create a "componentized" programming environment without the complexities of COM. COM still exists within the .NET Framework, and many .NET objects are simply wrappers around COM objects, but the complexities of COM itself is almost transparent to the developer. The problem with any major shift in programming paradigms, though, is transitioning from one state to the other. This being the case, the .NET Framework was built to work with components written using COM, and vice versa. This ability to work between managed .NET objects and objects written using COM is known as COM Interop.
In this hour you will learn:
How the .NET Framework is designed to handle .NET assembly and COM object communication
How to instantiate and use a COM object within a managed C++ application
How to use a .NET assembly and its associated classes within a native C++ application using COM
| Top |
No comments:
Post a Comment