At home I do a lot of interop with the Win32 API.  Over time after I saw myself writing the same interop code on several different projects so I started working on a centralized library for this type of code.  Originally I wrote this library in C#.  It was the language I used the most at the time and my brief experience with MC++ in Everret was too painful to justify using it. 

Recently I've started interoping with much more advanced structures.  I found that I was spending a lot of my time redefining structures, enums and defines that I am just using as a middle layer for the purpose of interop.  Tracking down the value for every enum is tedious and very time consuming.  This lead me to re-evaluate my choice of C# for the langauge since I could avoid this pain if I was using MC++. 

A quick aside here.  I am aware of several projects that exist where people have written scripts that will convert C++/C header files into their C# equivalent.  I avoid these for style reasons.  I find defines such as NERR_Sucess,  LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT unintuive.  When I write my interop layer I write enums that convert these into "more useable" types like so

public enum class LogonProvider

I was aware that MC++ had a lot of changes in Whidbey so I decided to try it out.  I must say that the new syntax for MC++ is a vast improvement over the original.  As a result I fully switched my interop library over to MC++.  After the initial learning period (< 1 week) I now find that I write my interop code much faster.  Most of the time saved revolves around not having to look up the values for #defines, enums and such.  This lets me fully devote my time to writing elegant wrappers for the Win32 API. 

Thus far I have only run into one issue that is caused a bit of grief.  The namespace System::Runtime::InteropServices defines a structure FILETIME.  Unfortunately, a similar structure is included in a lot of Windows header files (eg Lm.h).  So if you include one of those header files and that namespace you will get a compile error.  There does not seem to be an easy way around this. 

The best solution that I have found to this point is to typedef out all of the classes that I need from the namespace in stdafx.h like so

typedef System::Runtime::InteropServices::Marshal Marshal;
typedef System::Runtime::InteropServices::COMException COMException;

Overall I found the switch to MC++ for interop purposes in Whidbey to be a real time saver and I would recomend it to devs who write a lot of interop layer code