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.