Jesse Kaplan Program Manager Microsoft Corporation TL34.
-
Upload
toby-daniels -
Category
Documents
-
view
217 -
download
0
Transcript of Jesse Kaplan Program Manager Microsoft Corporation TL34.
Managed And Native Code Interoperability: Best Practices
Jesse KaplanProgram ManagerMicrosoft Corporation
TL34
Session Objectives When is Interop appropriate? Considerations for your interop architecture Choose an Interop Technology Preview of what’s next in interop
Takeaways Interop success starts with knowing when and
how to interoperate, and with choosing the right interop technology
Session Objectives And Takeaways
What’s already out there API level docs Tool descriptions 700 page tomes
The need: High-level architectural guidance that ties together the technology-oriented guidance we have today
Why This Talk?
Office VSTO Plug-in model
Expression Design MFC/WPF integration
Media Center
Interop Success Stories
1. Decide if Interop is right for you2. Architect your solution carefully 3. Choose the right Interop technology
Path To Interop Success
Interop is for you when you need To use new managed technologies
in your native app To leverage existing native code
in a managed app Provide a managed extensibility model
Don’t rewrite your application just to enable to managed code But, if you are going to re-write anyways, you
should strongly consider using managed code
Is Interop Right For You?
1. Decide if Interop is right for you2. Architect your solution carefully3. Choose the right Interop technology
Path To Interop Success
API Design and Developer Experience Native-managed transitions
and performance Lifetime management
Architectural Considerations3 high level points
Who is going to be coding against your interop layer?
What is their sophistication level? Do you want to optimize for their
experience or the cost of building that layer?
Interop API DesignDeveloper Experience
Interop API Design Strategies
Thin Layer
Rich Layer
Inte
rop
Managed code Native Code
Inte
rop
Managed code
MgdObject Model
Native Code
P/Invoke: Developer Experience
demo
Location of the interop boundary can have significant effects on performance
Interop Performance Strategies
Chatty or high-bandwidth interfaceIn
tero
pManaged
Application Native Library
Native Abstraction
LayerInte
rop
Managed Application Native Library
Pushing chatty interface into native layer
Abstraction layers can batch calls and aggregate data to reduce boundary crossing
Native app wants to use System.Xml System.Xml is a relatively chatty interface Where do we put the boundary?
First stab Between the app logic and the managed library
Can we do better?
Sample: Processing XMLNative App Consuming Managed Library
Native App
Engine
Inte
rop
System.Xml XML Proc
Inte
rop
Add a batching layer
Sample: Processing XMLMoving the Interop Boundary
Native App
Engine
System.Xml XML Processor
Native App
Engine
Inte
rop
System.Xml XML Proc
Batching Layer
Rewrite XML processing module in managed code
C++ /CLI: Moving theBoundary
demo
Lingering objects Stubborn GC Unloading
Lifetime ManagementCommon issues
Managed Code
PIA
Native Code
Originally there were only PIAs Over time we built up a much richer layer
Office ExtensibilityGoing Beyond PIAs
Office ApplicationIn
tero
pAdd-In
ManagerCOM
Extensibility Interface
PIA
Managed Wrapper
Add-In
COM Interop: Lifetime Managment
demo
1. Decide if Interop is right for you2. Architect your solution carefully3. Choose the right Interop technology
Path To Interop Success
P/Invokes Primarily a managed->native technology Create an Interop layer that
invokes simple C-style APIs C++/CLI
Create an Interop layer with /clr that bridges native and managed code
COM Interop Generate an assembly with tlbimp that exposes
COM types to managed code Generate a tlb with tlbexp that exposes
managed types to COM
Interop Technologies
Wraps C-style functions only Can be good if
You have few APIs to wrap APIs are simple: Signatures aren’t complex
May not be good if APIs use variable length structures, void*, etc. lots of APIs, to wrap but resources available
http://www.pinvoke.net Pinvoke Signature tool
Example: The .NET Framework BCL Wraps Win32’s flat C-style API and exposes
it to managed clients
P/Invoke
Designed to be a bridge between managed and native
Can be good if Static type-checking is needed Strict performance is a requirement More predictable finalization is necessary
May not be good if Other (simpler) Interop technologies
meet requirements Developers are not familiar with C++
programming paradigms
C++/CLI
Don’t use C++/CLI and just recompile your whole codebase with /clr C++/CLI works best as a bridge Performance of your code will decrease
when compiled with /clr Programmer productivity will be better in
either pure C++ or a pure managed language Compile exactly the files you need /clr
and no more E.g., your Interop layer written in C++/CLI Minimizes managed surface exposed to native
C++/CLIUsing /clr
Native application utilizes C++ classes Good fit for C++/CLI If app utilized COM, then CCWs could
also be viable Concerned with performance from
chatty interfaces that marshal large amounts of data
Using C++/CLIExample: Processing XML
Wraps COM interfaces Can be good if
You already use COM to componentize your application
You need full fidelity COM semantics May not be good if
Your native application does not use COM internally
COM Interop does not meet your performance requirements
Many tools are available to automate the process
COM Interop
Large Native application that wants managed add-ins Already utilized COM for extensibility Performance characteristics of COM interop
are acceptable For most applications Interop performance
is not a limiting factor Overhead of COM Interop is acceptable You can use different strategies to improve
performance
COM InteropExample: Microsoft Office
Decide if Interop is right for you Interop can provide the bridge Interop can help avoid a rewrite
Take the time to architect your solution and consider Developer Experience Performance Lifetime Management
Choose the right interop technology P\Invoke C++/CLI COM
Path To Interop SuccessRecap
What's Next In InteropMaking things easier and giving you more control
This started with Codeplex and will continue in .NetFx 4.0, Dev10, and beyond
Making things easier without hiding the details
Bridging the gap between the automagic of COM interop and the complete control of C++/CLI
What's New/Next On Codeplex
P\Invoke Signature Generating Tool Generates managed [DllImport] declarations
based on native header files Generates unmanaged definitions
for native delegates Managed TlbImp
Now: A managed version of the existing tlbimp Next: Managed tlbimp with
new features and extensibility options Better Diagnostics
Keep your eyes peeled when the betas hit Or you can just subscribe to our RSS feed…
P\Invoke Signature Generator
demo
What's New/Next In The .NetFX 4.0
Multiple runtimes in the same process Managed COM components run against the
version of the CLR they were built/configured against No More PIAs
IAs (optionally) move from runtime to design-time VB and C# compilers embed the portion of the IA an assembly uses
in that assembly The runtime makes these embedded types
equivalent between assemblies Override QueryInterface
ICustomQueriable allows you to take control Provide your own implementation for IDispatch,
IMarshal, or any other COM interface Aggregate managed COM components from within managed code
TL02 Under the Hood: Advances in the .NET Type System
PC49 Microsoft .NET Framework: CLR Futures
Relevant TalksCheck out the Videos…
Codeplex Site: http://codeplex.com/clrinterop P/Invokes
http://www.pinvoke.net COM Interop
.NET and COM: The Complete Interoperability Guide – Adam Nathan
C++/CLI http://blogs.msdn.com/vcblog http://www.marshal-as.net C++/CLI: The Visual C++ Language for .NET – Gordon Hogenson C++/CLI in Action – Nishant Sivakumar Expert Visual C++/CLI: .NET for Visual C++ Programmers – Marcus
Heege
For More Information About Specific Technologies
Q & A
Evals & Recordings
Please fill
out your
evaluation for
this session at:
This session will be available as a recording at:
www.microsoftpdc.com
© 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.