Rich Buchheim Senior Director Product Management Oracle Corporation
Misha Shneerson Senior SDE Microsoft Corporation Andrew Whitechapel Senior PM Microsoft Corporation...
-
Upload
victor-ellis -
Category
Documents
-
view
221 -
download
2
Transcript of Misha Shneerson Senior SDE Microsoft Corporation Andrew Whitechapel Senior PM Microsoft Corporation...
Under The Hood:Advances In The .NET Type System
Misha ShneersonSenior SDEMicrosoft Corporation
Andrew WhitechapelSenior PMMicrosoft Corporation
TL02
Agenda
Challenges in Enabling Extensibility Solution, Part I – Type Embedding Solution, Part II – Type Equivalence Putting it all together: Loose Type
Coupling and Extensibility Appendix: Improvements in Event
Handling for COM objects
User code Assembly
(50 Kb)
ChallengesDeployment of PIAs
Office 2007 PIA Redist(6.3 Mb)
Microsoft.Office.Interop.Excel.dll
(1.2 Mb)
Office 14 PIA Redist(6.3+ Mb)
Microsoft.Office.Interop.Excel.dll
(1.2+ Mb)
COM Interop Assemblies Complex deployment Targeting multiple host versions not supported Inefficiencies
Impact on working set Event helpers implementation
Managed-to-Managed Tight type-coupling Targeting multiple host versions is still hard
Challenges Implementing application extensibility
Type Embedding Key concepts
CLR 4.0 feature Internally we call this feature “NoPIA” Runtime dependency on Interop Assemblies
can be eliminated at compile time using per-reference /link switch
Information required to call into COM objects is embedded into the assembly itself
This information is represented by “local types” which are “partial” copies of types located in the Interop Assembly
IntelliSense,AutoComplete Type Information
Partial Type Information
Type EmbeddingDevelopment experience
Client Assembly
Local Types
VS Code Editor
Primary Interop
Assembly
C#/VBCompiler
Type Embedding For COM Interop Misha Shneerson
Senior SDEVisual Studio BizApps
demo
Type Embedding
Visual Studio option enabling Type Embedding of assembly references
To enable the same behavior from the command line, pass
the reference using /link
Type EmbeddingBasic rules
Only metadata is locally embedded interfaces (must have
ComImport, Guid attributes) delegates simple structs enums But not classes or static methods
Only types from Interop Assemblies can be embedded. Compilers check for these attributes [assembly:Guid(…)] [assembly:ImportedFromTypeLib(…)]
Type EmbeddingLocal types
Compilers create local partial types Local types are marked with
TypeIdentifierAttribute Using local types leads to reduced memory
working set Compilers track “used” methods of the
canonical interface, and only add those methods to the local interface definition _VtblGap pseudo methods are emitted in place
of unused methods to maintain vtable compatibility
Type EmbeddingFull type definition from an Interop Assembly
[ComImport][Guid(“E09335AA-9623-407b-AF63-5767CC6B7730”)]interface IFoo {
void Method1(IBar bar);void Method2();void Method3();void Method4();IBar Method5();void Method6();void Method7();void Method8();void Method9();void Method10();void Method11();void DoWork(void);void Method13();void Method14();
};
Type EmbeddingEmbedded partial local type
namespace FooLib { [ComImport] [Guid("E09335AA-9623-407b-AF63-5767CC6B7730")] [TypeIdentifier] internal interface IFoo { void _VtblGap1_11(); // Skip 11 v-table slots preceding DoWork void DoWork(); void _VtblGap2_2(); // Skip 2 v-table slots following DoWork }}
Type EmbeddingCustom code emitted for new operator
Instantiation of COM objects Legacy mode
IA contains classes with ComImport, Guid attributesCLR intercepts instantiation of such class and calls COM’s CoCreateInstance
Under NoPIA Problem: Classes can not be embedded Solution: Compiler analyzes the Interop Assembly,
finds the correct GUID and emits the following callActivator.CreateInstance(Type.GetTypeFromCLSID(guid))
Type EmbeddingCustom code emitted for event handling
Events Legacy mode
Registering an event on a COM object is intercepted at runtime by the CLR and forwarded to helper classes embedded in the Interop Assembly
Under NoPIA Compilers recognize when an event handler is
added/removed and emit a call to a new generic COM event handler
COM objects must use late binding to raise events (they usually do)
Type EmbeddingWorking with multiple assemblies
Typical applications use helper libraries Helper libraries also need to embed types Number of separate copies of
the same interop type are created Yes, these all are different types! Can we still use a method returning
a different copy of a type ?
Type Equivalence
Misha ShneersonSenior SDEVisual Studio BizApps
demo
Type EquivalenceKey concepts
CLR 4.0 feature Interfaces with the same GUID
are treated by CLR as equivalent types Casts to an equivalent interface
CLR looks for TypeIdentifier attribute to be present on one of the interfaces
Calls through an equivalent interface COM objects: CLR intercepts the calls and routes them
through COM interop (this is the old behavior) Managed objects: CLR finds an equivalent interface in
the inheritance chain, looks up a method with the same vtable offset, and verifies the signatures match
Type EquivalenceEquivalence of multiple partial local types
Assembly B
IFoo Partial Local Type
Assembly A
IFoo Partial Local Type
Foo : IFoo
void M(IFoo foo) { foo.DoWork(); }
At call time CLR verifies B’s
IFoo.DoWork has matching signature
as A’s IFoo.DoWork() and
invokes Foo.DoWork()
Loose Type Coupling In ActionManaged components in COM-based applications
Extensibility scenario for COM-based apps Write add-in code against any version of host Primary
Interop Assembly *Code must be adaptive to different versions of host
Embed local types using the /link compiler switch Deploy your application to any version of the host
without deploying the PIA Caveat: library assemblies must be:
compatible with the version host NoPIA-enabled
Example: Compile add-in against Excel 2007 PIA Deploy to Excel 2003
Loose Type Coupling In ActionManaged hosts and managed components
Extensibility scenario for managed apps APIs are published as interfaces into a
“programmability” assembly Add-ins embed these interfaces at
compile time Add-ins can be deployed to any version of the
managed host application without the need to deploy the programmability assembly itself *Code must be adaptive to the version of the host *Calling on a non-existing method will cause
System.MethodMissingException
Type EquivalenceAnd type safety
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 Incompatible calls on such interface will fail:
CLR ensures method signatures are compatible, so an attacker can not construct an illegal call
FullTrust is required for using type equivalence with structs
ConclusionsType embedding
Next version of C# and VB.NET compilers support embedding interface types into the caller assembly Simplifies deployment Simplifies multi-targeting support
when needed Reduces working set size Recompiling existing code should be a breeze
ConclusionsType equivalence
CLR introduces type equivalence support Type-safe Multi-targeting through interfaces Foundation for creating loosely coupled
extensible applications
Summary
Advances in .NET type system in CLR 4.0 Both managed-managed scenarios, and native-
managed C# and VB.NET
Interop/programmability types can be embedded Eliminates the dependency on interop assemblies or
programmability assemblies Simplified deployment, reduced working set
Type Equivalence Allows multiple assemblies, each with embedded
types, to communicate with each other Loose Type-Coupling and Extensibility Improvements in Event Handling
Evals & Recordings
Please fill
out your
evaluation for
this session at:
This session will be available as a recording at:
www.microsoftpdc.com
Please use the microphones provided
Q&A
© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
Appendix Improvements In Event Handling
COM objects use “Source Interfaces” to raise events
The source interface usually contains multiple methods, each one representing a different event
A COM client must implement the source interface to handle events. Each instance of the implemented source interface is known as an “event sink”
Improvements in Event HandlingEvents in COM-based applications
Issue: “Ghost” Runtime Callable Wrappers When adding an event handler to COM object,
the IA implementation registers an event sink one methods calls user’s delegate all other methods are stubbed
When a COM object calls the stubbed method on the event sink, there is a side-effect to marshal all the parameters, but no user code is called to have a chance to “clean up”. This creates “ghost” RCWs
“Ghost” RCWs interfere with COM’s deterministic life-time management rules by keeping COM objects alive until collected by GC
Improvements in Event HandlingEvents with Interop Assemblies
Performance hit: multiple COM interop transitions Every time you register a delegate to handle an
event, the IA implementation registers a separate COM event sink
The COM object calls all registered event sinks when it raises any event
Each call results in a separate COM Interop transition which negatively affects the performance of the application
Improvements in Event HandlingEvents with Interop Assemblies
User code
IFoo_SinkHelper- Event1- Event2 (stub)
o.Event1 += Event1Handler
IFoo_SinkHelper- Event1 (stub)- Event2
o.Event2 += Event2Handler
Event Sinks – Legacy (PIA) Mode
COM Host OM
IFooEvents- Event1- Event2
2. Forward Event1 call
1. Fire Event1
Host PIA
IFooEvents- Event1- Event2
IFoo_SinkHelper- Event1- Event2
Parameters marshalled
Parameters marshalled againand cause “ghost” RCWs
Improvements in Event Handling
// user types thisxlapp.SheetSelectionChange += userDelegate
// compilers analyze IAs and emit thisComEventsHelper.Combine(xlapp, sourceInterfaceIid, methodDispID, userDelegate)
Improvements in Event HandlingEvents with NoPIA
Generic COM event helper System.Runtime.InteropServices.ComEventsHelper When compiling with /link switch, C# and VB compilers
intercept event handler assignments and emit ComEventHelpers.Combine or ComEventHelpers.Remove
At runtime generic event sink is attached only one sink is attached per COM object to avoid multiple
COM interop transitions Assumption: COM servers fire events using late-bound
invocation (i.e. through IDispatch.Invoke) Early bound (aka “vtable”) event invocations are not supported
Parameters are only marshaled if there is a user delegate registered to handle the event to solve “ghost” RCWs
User code
EventHelper sink- Event1
e1 += new Event1_EventHandler
Event Sinks – Under NoPIA
COM Host OM
IFoo_Event- Event1- Event2
2. Forward Event1 call
1. Fire Event1
e2 += new Event2_EventHandler
EventHelper sink- Event1- Event2
Related sessions: TL16 Future of C# TL33 Managed Extensibility Framework:
Overview TL 34 Managed/Native Code Interoperability
Blogs: Misha Shneerson:
http://blogs.msdn.com/mshneer Andrew Whitechapel:
http://blogs.msdn.com/andreww VSTO Team: http://blogs.msdn.com/vsto
VSTO Developer Portal: http://msdn.com/vsto
Additional Resources
Session Objectives When is Interop appropriate? Considerations for your interop architecture Choose an Interop Technology Preview of what’s next in interop
Easier P\Invokes Customizing TlbImp PIAs as header files More
Takeaways Interop success starts with knowing when and
how to interoperate, and with choosing the right interop technology.
TL 34 Managed/Native Code Interoperability:Best Practices