The first session I attended on the first day of PDC was Misha Shneerson’s presentation on a feature affectionately called No-PIA, or formally enabled by type equivalence and type embedding.
The primary motivation for this feature is to simplify COM interoperability scenarios and improve their performance, but it is useful for managed-to-managed applications as well, particularly those with extensibility requirements.
What No-PIA means in brief is that instead of generating an interop assembly or using a primary interop assembly supplied by the COM component vendor, you can embed the required interop types into your own assembly. This is similar to what you could achieve by specifying the interop types by hand without using a PIA – but you no longer have to do that by hand!
If you opt-in to the No-PIA feature (by enabling a property in the Visual Studio references property grid, or using the new /link compiler switch), you don’t need the interop assembly anymore – which means it is not loaded and does not have to be distributed with your application. (Note that this feature is not intended for referencing managed assemblies – the referenced assembly must have an assembly-level [Guid] and [ImportedFromTypeLib] attributes. But it’s probably “work-aroundable” as I will explore in a future post.)
The feature is secure even though it doesn’t sound like it, because a verification is made every time a method is invoked. But don’t worry – the verification is cached so that it only happens once for each call site. Oh, and note that only the types and methods from the interop assembly that you actually use are embedded into your assembly – so this could be a huge space-saver if you’re automating Word to show a document but loading the whole Office interop assembly to do that.
However, that’s not all. Not only does the size of the interop assembly no longer have effect on your application’s distribution, but you can actually bind your code to previous or future versions of the COM component you are working with. This is enabled by the second part of the feature, called type equivalence, which requires a change in the CLR.
Type equivalence means that two different types with identical signatures can be considered equivalent by the CLR for the purpose of method invocation and cast operations. So you can compile your code against the (locally embedded) interop types of Office 2007, but if you’re not using any new Office 2007 features, your code will also bind to Office 2003.
This is actually useful for managed-to-managed scenarios as well – especially where extensibility is involved. If type A is decorated with a [Guid] attribute and another type B is decorated with the same [Guid] attribute and a [TypeIdentifier] attribute, then these types will be considered equivalent by the CLR, enabling casts and method invocations to succeed from one type to the other.
In turn, that implies that you can compile a plugin assembly against version 1 of the shared interface and execute it at runtime against version 2 of the shared interface without binding redirects or any other magic. In fact, if you also use No-PIA you don’t have to think about the shared interface assembly ever again!
To summarize, this is a really exciting feature that will enable easier interoperability and less headaches when producing and consuming extensibility applications. After the PDC I will certainly dive deeper into these features and showcase some possible scenarios that go out of the box.