Okay; I get why we're having different experiences.
When I'm writing managed code that needs to work heavily with COM, I write it in C++ using ATL, and expose that a level higher for calling from .NET. This avoids 90% of the issues you're hitting, while making it trivial to use COM from .NET (or, for that matter, any other non-C++ language).
The good news is that WinRT does legitimately solve most issues managed languages have. To me, far more importantly than WinRT's ability to export full-blown classes, is its ability to export much, much richer metadata, providing a straightforward way to work with WinRT objects from any language that can process the new metadata format. No more secret enums in header files, no more HRESULT insanity (HRESULTs are transparently mapped to exceptions). Just clean, cross-language calling. We've finally realized the original promise of COM.
Of course, that goal was met by "cheating." In my opinion, Microsoft achieved their goal merely by pushing the abstraction layer further into C++. In practice, I think that's an overall win--it certainly makes most of your points about using COM from managed languages moot--but it also means that your "native" libraries are going to be significantly more WinRT-specific. Or, if you prefer: instead of writing an ATL jacket to make the COM interface clean for .NET, I'll instead write a WinRT jacket to make a C++11 library clean for .NET.
When I'm writing managed code that needs to work heavily with COM, I write it in C++ using ATL, and expose that a level higher for calling from .NET. This avoids 90% of the issues you're hitting, while making it trivial to use COM from .NET (or, for that matter, any other non-C++ language).
The good news is that WinRT does legitimately solve most issues managed languages have. To me, far more importantly than WinRT's ability to export full-blown classes, is its ability to export much, much richer metadata, providing a straightforward way to work with WinRT objects from any language that can process the new metadata format. No more secret enums in header files, no more HRESULT insanity (HRESULTs are transparently mapped to exceptions). Just clean, cross-language calling. We've finally realized the original promise of COM.
Of course, that goal was met by "cheating." In my opinion, Microsoft achieved their goal merely by pushing the abstraction layer further into C++. In practice, I think that's an overall win--it certainly makes most of your points about using COM from managed languages moot--but it also means that your "native" libraries are going to be significantly more WinRT-specific. Or, if you prefer: instead of writing an ATL jacket to make the COM interface clean for .NET, I'll instead write a WinRT jacket to make a C++11 library clean for .NET.
The more things change...