Under The Hood: Advances In The .NET Type System

1. TL02 Under The Hood:Advances In The .NET Type System  MishaShneerson Senior SDE Microsoft Corporation  Andrew Whitechapel Senior PM Microsoft Corporation

2. 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

3. ChallengesDeployment of PIAs Office 2007 PIA Redist (6.3 Mb) User code Assembly (50 Kb) Microsoft.Office. Interop.Excel.dll (1.2 Mb) Office 14 PIA Redist (6.3+ Mb) Microsoft.Office. Interop.Excel.dll (1.2+ Mb)

4. Challenges Implementing application extensibility • 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

5. 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

6. Type EmbeddingDevelopment experience Primary Interop Assembly IntelliSense, AutoComplete Type Information VS Code Editor C#/VB Compiler Partial Type Information Client Assembly Local Types

7. demo Type Embedding For COM Interop  Misha Shneerson Senior SDE Visual Studio BizApps

8. 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

9. 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(…)]

10. 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

11. 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(); • };

12. 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 • } • }

13. 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))

14. 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)

15. 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 ?

16. demo Type Equivalence  Misha Shneerson Senior SDE Visual Studio BizApps

17. 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

18. Type EquivalenceEquivalence of multiple partial local types Assembly A Assembly B IFoo Partial Local Type IFoo Partial Local Type At call time CLR verifies B’s IFoo.DoWork has matching signature as A’s IFoo.DoWork() and invokes Foo.DoWork() Foo : IFoo void M(IFoofoo) { foo.DoWork(); }

19. 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

20. 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

21. 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

22. 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

23. ConclusionsType equivalence • CLR introduces type equivalence support • Type-safe • Multi-targeting through interfaces • Foundation for creating loosely coupled extensible applications

24. 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

25. Evals & Recordings Please fill out your evaluation for this session at: This session will be available as a recording at: www.microsoftpdc.com

26. Q&A Please use the microphones provided

27. © 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.

28. Appendix Improvements In Event Handling

29. Improvements in Event HandlingEvents in COM-based applications • 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”

30. Improvements in Event HandlingEvents with Interop Assemblies • 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

31. 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

32. Event Sinks – Legacy (PIA) Mode COM Host OM Host PIA IFooEvents - Event1 - Event2 • IFooEvents • Event1 • Event2 • IFoo_SinkHelper • Event1 • Event2 User code 1. Fire Event1 o.Event1 += Event1Handler • IFoo_SinkHelper • Event1 • Event2 (stub) 2. Forward Event1 call Parameters marshalled o.Event2 += Event2Handler • IFoo_SinkHelper • Event1 (stub) • Event2 Parameters marshalled again and cause “ghost” RCWs

33. Improvements in Event Handling • // user types this • xlapp.SheetSelectionChange += userDelegate • // compilers analyze IAs and emit this • ComEventsHelper.Combine(xlapp, • sourceInterfaceIid, • methodDispID, • userDelegate)

34. 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

35. Event Sinks – Under NoPIA COM Host OM IFoo_Event - Event1 - Event2 User code 1. Fire Event1 e1 += new Event1_EventHandler • EventHelper sink • Event1 • Event2 • EventHelper sink • Event1 2. Forward Event1 call e2 += new Event2_EventHandler

36. Additional Resources • 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

37. TL 34 Managed/Native Code Interoperability:Best Practices • 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.