INFO: Compile an IDL File for Proxy/Stub and not Type Library (236970)

SUMMARY

This article addresses why you should not compile an .idl file for both proxy/stub and type library unless you have a very specific reason to do so. Type libraries are limited because they support very few parameter types. For example, they do not support the [size_is], [switch_is], and [iid_is] attributes.

When Microsoft Interface Definition Language (MIDL) generates proxy code for unsupported types of a Distributed Component Object Model (DCOM) custom interface, and if it needs to generate a type library, MIDL tries to conform to the requirements of the type library and proxy/stub and sometimes cannot generate a valid Typelib (.tlb) file that equals proxy functionality. Therefore, it is essential that you do not compile the .idl file for both proxy/stub and type library.

MORE INFORMATION

If you use a wizard, change its default to generate only one type of output, preferably proxy/stub. By default, the Active Template Library (ATL) wizard generates the library block in the .idl file even when the arguments are not supported by the type library. The problem occurs when the attributes that are not supported by type libraries are used in the .idl file, and the .idl file is compiled for a type library.

You cannot include the [async] attribute in the type library. In addition, type libraries only support those data types that are supported by scripting languages. For example, type libraries do not support the following Remote Procedure Call (RPC) attributes:

Pointer attributes
- [ref]
- [unique]
- [ptr]
Field attributes
- [size_is]
- [length_is]
- [switch_is]
- [iid_is]

When an unsupported attribute is found in an interface that is generated into a .tlb file, it is ignored. For example, when the [size_is] attribute is used for a pointer to denote a conformant array, the type library represents that as a single pointer. In some rare cases, proxy generation problems may occur when an invalid .tlb file is generated unnecessarily. Use a /notlb switch to prevent unnecessary .tlb file generation.

Also, if you compile both type library and proxy/stub for a custom interface, make sure that you register the proxy/stub (and not the type library) for the interface. If you register the type library for the custom interface, the interface marshaling may behave incorrectly. For example, if a method uses the [size_is] parameter, and the type library is registered, the .tlb file drives the marshaling. In this case, the parameter is not marshaled back correctly (for example, only the first element of the array is sent back) because the type library has no concept of [size_is]. This behavior occurs whether subsequent unmarshaling goes through the .tlb file or with proxy/stub. When unmarshaling goes through proxy/stub, most likely the bad stub data exception as the array is missing in the marshaling buffer. When unmarshaling goes through the .tlb file, the unmarshaling succeeds, but most likely the remote client/server dies because it expects an array and not a single pointer.