COM interoperability is a very powerful feature in the CLR that bridges the gap between native and managed code. It lets you reuse your existing COM and non-COM native DLL in the managed environment easily. It also lets native code call back to managed code in a seamless way.


It provides a wealth of features which I wanted to talk about here in some detail.


  1. tlbimp
  2. tlbexp
  3. tlbref
  4. regasm
  5. RCW and Life Time Management
  6. CCW
  7. Marshalling and Custom Marshalling
  8. pInvoke
  9. Eventing
  10. System.Runtime.Interopservices namespace
  11. MDA and debugging
  12. Threading/Apartment/Context
  13. Availability of documentation with code samples


There are inherent differences in the way native code, COM code and managed code work. This adds to lots of confusion in the ways they interact and work together. This in my opinion has been a significant pain point for users of this technology. I also feel that this area is highly complex when it comes to identifying and solving a scenario, task or problem that you have to solve. As an example, I have been asked the question of when should users use custom marshalling many times now. We want to make the user/developer experience with this feature better and are looking for some input on the same. Here are some questions that I have that will help me understand the problems that our customers face with this technology



  1. Knowledge/Skill of user
    1. Is your usage of COM primarily as a component consumer (e.g. via RAD-style usage in an IDE) or component developer (e.g. via ATL)?
    2. Have you developed a COM/Unmanaged component in a commercial software package?
    3. Have you developed a commercial software package on the Visual Basic platform (specifically VB6/VB.NET)?
    4. Do you view your usage of COM Interop as transitional/migratory, or is it a permanent element of your architecture going forward? How skilled are your developers with unmanaged, COM and managed code?
    5. Has the COM Interop functionality from the CLR played a role in your application compatibility / backwards compatibility story? Do you find your adoption of .NET is biased by legacy needs?
  2. Customer Scenario and choice of technology
    1. What is your end user customer scenario? (Ex: Five components A, B, C, D, E. A is a legacy COM component. B is our UI/Business application in C# which needs functionality from A. etc)
    2. What is the scenario inside that which drives you to use COM interop as a solution? (Ex: Reuse of existing functionality/library that is available in Com from managed code. Exposing managed API’s for COM to customers etc)
    3. How did you decide that COM interop was the best solution for the problem?
    4. How difficult was the decision and what were the alternatives that you considered? (Ex: complete native implementation, re-implementing in managed, managed C++ bridge, COM interop etc)
    5. What features of COM interop do you use and for what scenarios and reasons? If disparate state them separately with explanation. (Ex: tlbimp, RCW, CCW, Eventing, pInvoke, Marshalling etc)
    6. What is the diversity of your environment in terms of architecture (32 and 64 bit) and languages (C++, COM, VB, C# etc)?
  3. Developer experience during development
    1. Do you use the COM interop technologies from Visual Studio or from command prompt? (Ex: run tlbimp from command or import through Visual Studio)
    2. What parts of the COM interop technology from the list above does development use to solve the above scenario?
    3. What is the heaviest of the above that makes the meat of the product? (Ex: Marshalling, Eventing etc)
    4. What are the most complicated problems that you have encountered during development and in which areas?
    5. How do you investigate problems in this area? (Ex: Use MDA, Debug using windbg etc)
  4. Servicing experience
    1. Have you encountered significant end user problems because of failures in your COM interop later? If yes, which part of COM interop did they come from? (List top 4 areas)
    2. What were the problems in most of the cases? Was it with the platform or your implementation?
    3. How did you identify the problem?
    4. How did you solve the problem?
  5. Debugging experience
    1. How do you debug problems in COM interop?
    2. Do you use windbg, SOS, public symbols etc?
    3. Do you use MDA’s for your debugging? (
    4. Do you look at you native and managed code in oleview and ildasm, reflector to see what is happening under the hood?
    5. What is your average time spent in a problem in this area? How many problem have you seen in this area in a given product cycle (months)?
  6. Help and documentation available
    1. What specific material do you refer for this area and how useful is it?
    2. Do you know about Do you use it?
    3. How would you rate MSDN documentation for this area? What is lacking if any?
    4. Do you find enough samples available to get you on the ramp with the various technologies here?
    5. How do you rate our help and documentation on MDA’s?
  7. Other – Any other things that you want us to know

I want to be clear that I am not looking for adding new features to this area, but looking for making the experience with the current features easier and better. Your input here will be valuable in driving this technology in the right direction.