COM, Unmanaged/Managed C++, and CoInitialize()

[Michael Kennedy [UB]]

Hi,

I'm working on a project which makes use of COM in unmanaged C++. That
unmanaged C++ is then wrapped in a managed C++ class. Finally, this managed
C++ class is then consumed in a C# application. It looks like this:

C# App
|
| (one-to-many relationship)
|
|- Managed C++
|
| (one-to-one relationship)
|
|- Unmanaged C++
|
| (one-to-many relationship)
|
|- COM

My question what is the best way to handle the call(s) to
CoInitialize()/CoUninitialize() for the COM being used in the unmanaged C++?
As far as I know I have the following options:

1. Add a call to CoInitialize() in the constructor for the unmanaged C++
class and a call to CoUninitialize() in the destructor.

2. Add a static pair of methods to the unmanaged C++ class and call them at
the beginning / end of the C# app using either static methods in the managed
C++ or via PInvoke.

Now method 1 doesn't work for me because I may have more than one instance
of those classes and the destructor for the first one could clobber the COM
apartment for the second class before it's done with the COM objects it's
using.

As far as I can tell, the STAThread attribute doesn't actually initialize
the COM system in the unmanaged C++ and only applies to the managed C++ and
C# right?

How are you handling this? Is there an easier way to do this? Maybe some
magical attribute that I'm not aware of?

Thanks,
Michael

 

[Mattias Sjögren]

Michael,

As far as I can tell, the STAThread attribute doesn't actually initialize
the COM system in the unmanaged C++ and only applies to the managed C++ and
C# right?

COM initialization is something you do on a per-thread basis. So if
the C++ code runs on the default C# thread, COM has already been
initialized by the CLR.



Mattias

 

[Klaus H. Probst]

As far as I can tell, the STAThread attribute doesn't actually initialize
the COM system in the unmanaged C++ and only applies to the managed C++ and
C# right?

No. The apartment is initialized after the first call to unmanaged code
occurs. Before that you can set it through
Thread.CurrentThread.ApartmentState. After the first call you can't touch
it. And if you don't set it, it's either set to the default or it picks up
the attribute, if present.

How are you handling this? Is there an easier way to do this? Maybe some
magical attribute that I'm not aware of?

Like Mattias said, it's a per-thread issue. If all of your code is running
in the same thread (and/or the same process) then you need to keep in mind
that the CLR already called CoInitialize[Ex] for you. But again, this
happens only until the first call to unmanaged code occurs.

 

[Michael Kennedy [UB]]

Hi Mattias,

Thanks for pointing this out to me. So the STAThread attribute does handle
this well. I guess the last time I tested this scenario I didn't carefullly
pay attention which threads were doing what.

Thanks again,
Michael

 

[Michael Kennedy [UB]]

Hi Klaus,

Thanks for the information. Last time I wrote something like this I guess I
didn't pay enough attention to my threading. I wrote a few tests for this
last night and it works like a charm.

Thanks again,
Michael

As far as I can tell, the STAThread attribute doesn't actually initialize
the COM system in the unmanaged C++ and only applies to the managed C++ and
C# right?

No. The apartment is initialized after the first call to unmanaged code
occurs. Before that you can set it through
Thread.CurrentThread.ApartmentState. After the first call you can't touch
it. And if you don't set it, it's either set to the default or it picks up
the attribute, if present.

How are you handling this? Is there an easier way to do this? Maybe some
magical attribute that I'm not aware of?

Like Mattias said, it's a per-thread issue. If all of your code is running
in the same thread (and/or the same process) then you need to keep in mind
that the CLR already called CoInitialize[Ex] for you. But again, this
happens only until the first call to unmanaged code occurs.