News

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

.NET 4 Feature Focus: Type Embedding and Equivalence

Posted by Jonathan Allen on Oct 27, 2008

Sections: Architecture & Design,; Development
Topics: VB 10 ,; Runtimes ,; Visual Basic.NET ,; .NET Framework 4.0 ,; C# ,; Java ,; .NET Framework ,; .NET Languages ,; Languages ,; .NET ,; C# 4 ,; Programming ,; Interop ,; COM

Probably the most common problems with COM Interopt in .NET applications is deployment and versioning. Currently developers have to include "Primary Interopt Assemblies", which in the case of applications like Office be a megabyte or larger. With .NET 4 that will no longer be an issue.

COM Type Embedding allows fragments of interfaces to be compiled into the assemblies that need them. Only the interfaces and methods actually used by the program are included, drastically reducing the overall size of the application.

To keep the VTables accurate, gap commands are included in the assembly's IL as placeholders. These indicate how many method slots are to be skipped. Since COM doesn't allow methods to change location in published interfaces, this will allow support for both forward and backwards versioning.

Another issue this addresses is compiling an application against a newer version, say Word 2007, when the end user may have Word 2003. Checking to see if a method actually exists in the runtime version will have be done in user code, otherwise an access violation will occur. But so long as only backwards compatible methods are used, there should be no other issues.

The use of this will be controlled via a compiler flag. It will default to off for old projects and on for new ones. In the rare event that COM Type Embedding won't work for a given COM interface, a compiler error will occur recommending the flag be turned off.

Two related features are Type Equivalence and Managed Type Embedding. These allows types in different assemblies to be treated as being the same type at runtime. This is crucial for scenarios where multiple libraries are pulling in the same COM interfaces. There are strict rules on this. First of all, all types have to be tagged with a shared GUID so they can be matched up. This isn't an issue with COM, since they are tagged anyways, but it will have to be explicitly applied to managed types.

Regular classes cannot be shared via Type Embedding and Equivalence due to the possibility of differing implementations. Types that can be shared include interfaces, enumerations, delegates, and simple structures.

These features are planned for VB and C#. Developers using C++/CLI normally access COM objects via their header files and Microsoft does not currently plan to offer it for them.