|
COM Programming with Microsoft .NET Authors: Templeman J., Mueller J.P. Published year: 2006 Pages: 24-25/140 |
 |
|
|
Summary
In this chapter, youve learned about the place of COM+ in the .NET developers toolbox. Its still an important technology for the developer of distributed applications. In most cases, COM+ complements the capabilities that .NET provides, so combining the two makes sense for the present. Eventually, Microsoft will replace COM+ with something that uses .NET directly, but for now, you still need this technology to make some types of distributed applications work.
Youve also learned about two handy MMC snap-ins. Actually, the developer should know about most, if not all, of the MMC snap-ins because they all provide handy administration functions. For example, youll find the snap-ins provided in the Performance console handy when you want to analyze the performance of your application on various systems. If you havent already spent time working with the various MMC snap-ins, you might want to do so now. Youll want to have a variety of tools at your disposal as you work through the examples in this book.
Chapter 3 shows you how to use COM components in your .NET application. Youll learn about several tools that come with the .NET Framework that make this job easier. Chapter 3 also helps you understand how .NET interacts with COM. Finally, youll learn how to build COM components that not only work well with unmanaged applications, but also interact well with managed applications.
|
|
|
|
Chapter 3: Using COM Components in .NET Code
Now that we have looked at the way in which COM and COM+ fit in with the .NET world, we will move on to more specific topics in the next three chapters. To start with, this chapter looks at how COM components can be used in .NET code. Microsoft has taken care to provide backward compatibility in .NET for COM so that existing investment in COM components doesnt have to be abandoned when you move to .NET. The design of .NET makes it possible to use COM components as if they were native .NET components and will even let you use ActiveX controls in the Microsoft Visual Studio .NET Toolbox.
This chapter will show you how to use COM components and ActiveX controls in .NET projects. Youll see how COM coclasses and interfaces are represented in .NET, and how marshaling works between .NET clients and COM components. In the following chapters, youll see how to use .NET components in COM and COM+ code.
COM Interop: Principles and Mechanisms
The common language runtime needs to have metadata for all the types used in .NET code, including imported COM types. Because metadata is included as part of .NET assemblies, the metadata for COM types must somehow be held in an assembly.
Interop Assemblies
An assembly that represents a COM object to a .NET client or vice versa is called an interop assembly . As youve seen, there are two kinds of interop assemblies: Runtime Callable Wrappers (RCWs) that let COM objects be referenced by .NET clients, and COM Callable Wrappers (CCWs) that let .NET components act as COM objects.
There are three ways of producing interop assemblies using tools and classes provided by .NET. These three techniques, listed in order of increasing flexibility, are
-
Using the tools provided by Visual Studio .NET
-
Using the type library importer tool, TlbImp.exe, which is part of the .NET Framework
-
Using the System.Runtime.InteropServices.TypeLibConverter class
Youll see how to use each of these later in the chapter.
Each of these three techniques requires that a type library be available from which to generate an interop assembly. What if the type library isnt available, or the interop assembly is incomplete or needs tweaking? In those cases, you can create interop assemblies directly, using suitable attributes in .NET code. The techniques used to do this are covered in Chapter 14, Working with Predefined Interfaces.
Primary Interop Assemblies
Anyone can produce an interop assembly for a COM type library simply by running TlbImp.exe. If several vendors produced interop assemblies for a commonly used COM component, a client machine could end up with several interop assemblies that differ only in the details of who has produced them. This situation not only clutters machines with multiple copies of functionally identical code, it can also introduce problems. Consider the following scenario:
Two independently developed .NET applications (MyApp and YourApp) both make use of the same COM component and have generated their own interop assemblies. This shared COM component exposes the IComp interface.
MyApp exposes a method that needs to be passed an IComp reference. If YourApp calls the method, it will pass a reference to its own interop assembly. And this is where the problem rears its head: the two interop assemblies are signed with different keysone for MyApp and one for YourAppso .NET regards them as completely different entities. The fact that they are functionally equivalent makes no difference: MyApp will not be happy to be passed a reference to an interop assembly signed by YourApp.
A primary interop assembly (PIA) is a unique, master interop assembly that represents a COM component. Only the publisher of a type library can produce an official PIA, so vendors will use this mechanism to distribute interop assemblies that represent their COM types. It is important that only one primary interop assembly is produced for each COM type and that version numbering is strictly enforced. Otherwise, incompatibilities might be introduced. Note that the names and marshaling behavior of PIAs arent required to exactly match that of the underlying COM object, so they can be changed to make interoperation work more efficiently .
|
PIAs must fulfill certain requirements:
-
They must include all the COM types defined in the original COM library and maintain the same GUIDs.
-
They must be signed with a strong name .
-
They must use the PrimaryInteropAssembly attribute.
-
They must avoid redefining external COM types.
-
They can only reference external COM types that are themselves represented by a PIA.
Because they are designed to be used by all clients on a machine, PIAs will normally be installed in the Global Assembly Cache (GAC).
Note You should always use the primary interop assembly provided by the supplier of a COM component, if one is available, rather than producing your own interop assemblies.
|
|
|
|
|
COM Programming with Microsoft .NET Authors: Templeman J., Mueller J.P. Published year: 2006 Pages: 24-25/140 |
|
Similar books on Amazon
Similar books
Similar materials
- What You Have Learned
- 7-1 distribute-list access-list-number in
- Chapter 12 -- Designing Distributed Applications
- Section 6.3. Technology Disciplines Covered Under CMMI
- Still More Complex Example: Object Creation and Method Invocation
- 35.2 TECHNOLOGY INGREDIENTS OF CTI
- YADDES-Yet Another Distributed Discrete Event Simulator: User Manual
- Understanding Distributed Transactions
- MMC Administration
- Microsoft Management Console