24.5 Viewing the RCW Using ILDasm.exe

24.5 Viewing the RCW Using ILDasm.exe

You want to ensure the RCW was created correctly for a type library.

Technique

ILDasm.exe is in the Visual Studio .NET 2003 SDK bin directory. After running the application, open an interop assembly from the file menu. One thing that will become apparent is the amount of data types that are present compared to what you see in the actual COM object itself. Some of these data types are created during the type-library-to-assembly translation and are used by the CLR to aid in event handling between a COM and .NET object.

As an example, we are going to create a new method within the COM object that will accept an array of commands to send to the command interpreter and then generate an interop assembly to see how the marshalling will occur. Assuming you created the COM object from Recipe 24.1, right-click on the main interface, ICommandCom in this example, and select the Add Method menu item. The method name is ProcessCommands and the parameters include an in parameter whose data type is SAFEARRAY (BSTR)* with a name of Commands and a second parameter, a pointer to a BSTR ( BSTR* ) that will hold the resulting output. The implementation of the method is unimportant because we are only interested in viewing the generated intermediate language (IL) for the interop assembly.

After building the project and generating an interop assembly, either by adding a reference to the COM library or using the automatic method explained in Recipe 24.3, open the assembly in ILDasm.exe . Expand the CCommandCom class or ICommandCom interface, and double-click on the ProcessCommands method. A new form appears, showing contents similar to the following Microsoft Intermediate Language (MSIL) code:

 .method public hidebysig newslot virtual     instance string  marshal( bstr)  ProcessCommands(     [in] class [mscorlib]System.Array  marshal( safearray bstr) commands)     runtime managed internalcall { .custom instance void [mscorlib]System.Runtime.InteropServices.DispIdAttribute ::.ctor(int32) = ( 01 00 05 00 00 00 00 00 ) .override CmdShell.ICommandCom::ProcessCommands } // end of method CCommandComClass::ProcessCommands 

The portion of this MSIL code that we are interested in is the parameters of the ProcessCommands function. The first parameter of the method takes a System.Array method and marshals it as a SAFEARRAY whose data type is a BSTR . One reason why we chose this example is to show you that you shouldn't believe everything you read and you need to understand the Visual Studio .NET toolset to get the real answer. The MSDN documentation for SAFEARRAY marshalling still uses the documentation for version 1.0 of the .NET Framework. The documentation states that the interop assembly creates a reference to a string array, and you must export the IL code, change it to a System.Array , and then recompile the IL to create the interop assembly. As you can see, however, the behavior of the tlbimp.exe translation has changed, and it now creates the proper .NET data type. By understanding ILDasm, you can easily verify the information before going through the painstaking processes only to find out that it was all for naught.

Comments

ILDasm is an important and extremely helpful tool to use when developing .NET applications. Not only does it aid in understanding how .NET objects interact with the CLR during runtime, but you can also use it to pinpoint performance issues and, in this case, inspect interop assembly marshalling.