Learn how to interoperate between managed and unmanaged (native) code, including COM interop. Learn how to consume native code from managed libraries, and how to expose managed libraries to native code. Notes from CLR Program Manager Joe Duffy... Slide 1: Sonja has since moved on to take on responsibility for the JIT, so she finally got to work on more than just Interop! She’s still a resident expert in this area of course. Some good blogs for folks on interop team are as follows: Adam Nathan is the test lead for interop (and has written a great book on the subject), and Chris Eck is the lead developer on the team. Slide 5: Given that the CLR and .NET Framework was originally rumored to be called COM3, COM+ 2.0, and the COM+ Runtime, it shouldn't be a surprise that COM Interop was a high priority all throughout its design. Chris Brumme has a ton of great articles about how this ultimately had an impact on the CLR’s design on his blog: Managed objects & COM, Apartments & Pumping, ReleaseComOjbect, and many more. Slide 6: If you look closely, you'll see a whole bunch of _Type-like classes in the System.Runtiome.InteropServices namespaces... _Exception, _Thread, and so on. Sonja also talks about versioning... We recently had a situation where we wanted to add a private field to the System.Threading.LockCookie struct, but then realized it was COM-visible. Adding a new field changes the layout of a value type’s data structure, which would cause lots of problems on existing COM clients, resulting in access violation crashes all over. Beware of this! Once you ship a COM-visible value type, you're locked in forever!... Needless to say, we didn’t change it. LockCookie2 anybody? :) Slide 7: COM-friendly APIs are in a world of their own, and pretty much have their own set of DesignGuidelines. Many of the API-related FxCop rules don't apply. Slide 8: Check out the new and improved C++/CLI compiler that ships with v2.0. Herb Sutter's blog is a great place to stay tuned in to for a constant stream of information. For example, this post talks about the /clr:safe switch. Also, most of what you'd ever need (and surely more than you'd ever want) to know about AppDomains can be found here. Slide 15: Truthfully, most people will end up dealing with managed->native interop an order of magnitude more than native->managed. This is a testament to both the amazing growth of managed code adoption as well as the richness and breadth of existing Win32 and native libraries... The combination of these two things is surely one of the factors that make writing in managed code great. Slide 17: The P/Invoke Wiki is indispensable for doing P/Invoke unmanaged interop... With tools like a VS plug-in, and a whole host of annotations around specific available Win32 APIs, it can make doing native Interop as easy as browing to the API you want to hook into, and cutting & pasting the sample code from the Wiki. Slide 20: C++ Interop is a great approach if you intend to develop with managed C++. As mentioned above, the new C++/CLI has a ton of great features to give CLR develops more power. You can find some specs on the new language features here, and a useful “Hello, World” article here. Slide 24: SafeHandle and critical finalization was recently a topic on the BCL Team's blog day. Check out the results here: "SafeHandles: the best V2.0 feature of the .NET Framework" and "SafeHandle: a Reliability Case Study". Also check out the new GC.AddMemoryPressure API and HandleCollector class, both of which facilitate collecting dangling handles under pressure. |
.jpg)