PDC08 - Under the hood: Advances in the .NET Type System (Live Blogging)

Presenter : Misha Shneerson - Senior SDE - Microsoft

Agenda - Its all about COM interop
Solution - Type Embedding
Solution - Type Equivalence
Putting it all together - Loose type coupling and extensibility
Improvements in event handling for COM objects

Deployment of PIA (Primary interop assemblies) is a big issue.

SAy you have an Interop solution with office - Usercode assembly size (50kb) the interop assembly interop.excel.dll for example is 1.2MB

The problem is installation... we need to install office 2007 PIA redist - 6.3MB

Today: In order to deploy 50k we need to install 6.3MB !

If we are targeting office 14 we need to install office 14 PIA redist 6,3MB+...

COM Interop - There are some efficiency in interop assemblies - event support.
Managed to Managed - there might be file missing prob... as version do not match

Type Embedding - Get rid of interop assemblies to be embeded into the process
CLR 4.0 feature
Both C# & VB can pass ref to assembly via /link like /ref the compiler will look at the type and embed this type, all the information is now embeded into the assembly.

A new property in the prop managed of VS for assembly that we have ref which is Embed Interop = true

If we open the assembly in ildasm there will be 2 namespace the application one and an Microsoft.Office.Interop.Excel namespace the second one will include the types that have been pulled.
you will notice a _VtblGap1_X stubs the X is the number of slots to skip as the table due to the pull. (Methods not being embeded stack out by vtable gaps)

Limitation of what can be embeded:
only metadata - not il !
Interfaces must have comimport, guid attributes
we can embed delegates
we can embed simple structs
we can embed enums
but not classes or static methods !

Type Equivalence - Very easy to write addins with it ! - helps build a loosely coupled apps !

CLR 4.0
Interface with the same guid are treated by the LR as equivalent types
Casts to an equivalent interface
  CLR looks for Typeidentifier attribute to be presented on one for the interfaces

How does it work ? The clr walk the chain find the equivalence, very the signatures to see that they are matching and if they are the call with go through. (The CLR check that you are not doing unsafe calls)

Is it not heavy ? first time yes but the next time it will be cached.

When you write adding for com based app you can write against any version of host primary interop assembly - you embed local types using the /ink compiler switch

If you try to work against office 2007 and then try to work with the adding in office 2003 - the vtables are different so you will get an access violation exception.

Addins for managed hosts
apis are published as interfaces into "programmability" assembly.
Add-ins embed theses interfaces at compile time.

Is type safety a concern ?
it is possible to construct an interface that is type equivalent to another interface but which is completely incompatible with that interface.

casts to such an interface will succeed

The next version of the clr when you add a ref to interop assembly the embed switch will be automatically added

Samples will be available at Misha's blog

No Comments