tailieunhanh - Pro VB 2005 and the .NET 2.0 Platform Second Edition phần 6

Thuộc tính privatePath là điểm then chốt trong ví dụ này, vì nó được sử dụng để chỉ định thư mục con liên quan đến các thư mục ứng dụng CLR nên thăm dò. Do lưu ý rằng các phần tử không xác định lắp ráp được đặt trong một | CHAPTER 17 COM AND .NET INTEROPERABILITY 497 As you can see consuming a COM type from a .NET application can be a very transparent operation indeed. As you might imagine however a number of details are occurring behind the scenes to make this communication possible the gory details of which you will explore throughout this chapter beginning with taking a deeper look into the interop assembly itself. Investigating a .NET Interop Assembly As you have just seen when you reference a COM server using the Visual Studio 2005 Add Reference dialog box the IDE responds by generating a brand-new .NET assembly taking an Interop. prefix such as . Just like an assembly that you would create yourself interop assemblies contain type metadata an assembly manifest and under some circumstances may contain CIL code. As well just like a normal assembly interop assemblies can be deployed privately . within the directory of the client assembly or assigned a strong name to be deployed to the GAC. Interop assemblies are little more than containers to hold .NET metadata descriptions of the original COM types. In many cases interop assemblies do not contain CIL instructions to implement their methods as the real work is taking place in the COM server itself. The only time an interop assembly contains executable CIL instructions is if the COM server contains COM objects that have the ability to fire events to the client. In this case the CIL code within the interop assembly is used by the CLR to manage the event handing logic. At first glance it may seem that interop assemblies are not entirely useful given that they do not contain any implementation logic. However the metadata descriptions within an interop assembly are extremely important as it will be consumed by the CLR at runtime to build a runtime proxy termed the Runtime Callable Wrapper or simply RCW that forms a bridge between the .NET application and the COM object it is communicating with. You ll .