. Net 4.0: Type equivalency (1)-Byebye, Pia

In. Net 4.0 CTP, the most notable improvement of InterOP is type equivalency, which is also called no Pia. Before introducing how to use this new feature, I think we should start from the history to explore what we actually want to solve and what solutions we used in the past, and the problems with these methods.

In. net, to access COM objects, You need to define a series of hosted interfaces, struct, and class. With the typelibrary, you can use tlbimp to automatically generate an assembly, which is called InterOP assembly (IA). It contains the types corresponding to typelibrary, for example, the result of tlbimp stdole2.tlb is:

Then, the program written by the developer can directly reference this DLL and use the type defined in it to access the corresponding COM object. In a single program, this model works quite well.

However, in actual projects, we may encounter the following problem: Company A releases a COM component A and synchronously releases the corresponding one. net wrapper, and referenced to a type in stdole. The developer of this component A chooses to use tlbimp to generate an InterOP assembly corresponding to stdole2.tlb, which we call stdolea. At the same time, another COM component B, developed by Company B, also has a copy of its own stdole for similar reasons, known as stdoleb. The two companies obviously do not know each other, so they cannot cooperate to share a copy of stdole, and the cooperation will bring about various dependencies, neither company is willing to introduce dependency on the other party. Moreover, these two components are signed and cannot be modified to point them to our own stdole. dll. It is not realistic and inconvenient to regenerate their own wrapper, because their wrapper has some convenient helper defined by them.

Once two different stdole. DLL,. for net/CLR, stdolea and stdoleb are different DLL. Although their definitions are identical, the types are identical, but the types are completely different, because these types have different identities ). Compiler /. net/CLR do not allow two stdole. the types in DLL are used interchangeably without type conversion. In some cases, direct conversion is illegal for struct.

To solve this problem,. NET introduces a concept called Pia. For a publisher of a Type Library, an "official" InterOP assembly can be provided. Other assemblies directly reference this InterOP Assembly instead of using tlbimp to generate their own copy, in this way, you can use a copy to solve the problems mentioned above. This special InterOP assembly is called primary InterOP assembly (PIA. Pia should be signed and registered to GAC. Pia is usually provided by office.

However, during a long period of practice, we found a new problem brought about by the introduction of Pia:

1. Pia deployment is difficult

A. For a type library, it is often difficult to determine who is the final owner and who is responsible for releasing this Pia. It is very simple for office, but for the above stdole example, does windows also need to publish a PIA for all windows TLB instances? What should I do if XP does not contain. NET Framework?

B. Generally, Pia is deployed when the COM component and typelib are installed. For example, when installing the office, word/Excel and so on all have corresponding COM components (strictly speaking, these applications are both com servers) and typelib, the corresponding Pia will also be installed in GAC during installation. However, if the. NET Framework is not installed on this machine, Pia cannot be installed.

2. unable to customize Pia: Once Pia is released, you cannot modify Pia. Once the type definition in Pia does not meet your requirements, developers may define their own versions, this means that we are once again in a dilemma.

3. Pia size: Pia is usually very large, especially for com-enabled applications such as office, it is easy to reach around 1 m

4. Pia version: the COM component has its own particularity. Once an interface is defined, the interface cannot be changed. If you have written a program that can use the imyobject interface to access the COM component, the new version of the COM component can also be accessed through the imyobject interface, and possibly through the imyobject2 interface. The old program can directly use the new COM component without modification. For Pia, if the program you write references an old version of Pia, we recommend that you install the COM component at the same time, release a Redirection policy to relocate all references to the old version to the new version of Pia, so this program can still work on the new version. However, if the program you write references a new version of Pia, you cannot use the latest version of COM in the old version. Even if you only use the imyobject function of the old interface, in theory, the old version of COM components can be used. The cause is Pia.

5. Bind a strong-type RCW: Pia usually has a strong-type RCW. For COM, it is designed for interfaces and is not suitable for binding to a static type. For more information about strong and weak types of RCW, see my previous article: What is system. _ comobject: strong type RCW and weak type RCW

Since Pia has so many problems, how can we solve them? In fact, this issue can focus on its nature: the initial issue was that the managed types of different identities correspond to the same unmanaged com type (such as interfaces ). So let's look at another way of thinking. What if we allow. Net/CLR to really consider these two types as one? In fact, most of the COM types have guid as the unique identifier. Therefore, for the hosting type corresponding to the same com type, their guid must be the same, this provides the foundation to recognize them as the same managed type, which is the main content of the type equivalency function. Because Pia is no longer used when this function is used, it is also called no Pia internally. In the next article, I will explain how to use it based on actual examples. net 4.0 + Visual Studio 2010 CTP, demonstrate how to use the type equivalency function. net and C # compilers work together to avoid using Pia and solve the issue of inconsistent hosting types.

--
Author: atfield)
Blog: http://blog.csdn.net/atfield
Http://blogs.msdn.com/yizhang
Reprinted please indicate the source