CoInitializeEx... safe to run on main thread?

[bad6oy30]

I'm moving from out-of-process to in-process, and I have to reinvent the wheel as far as injection and detour goes... using someone else's lib is like paying someone to build my hobby-car

I want to use c# to do the work. Is it OK to initialize COM on wow's main thread (in an endscene detour that will be doing my work)?

If not, I can use a worker thread approach and just put a signal-and-wait in the endscene detour... but then does my worker thread need to adopt the main thread's TLS for wow's functions work behave right?

[adaephon]

Reading from MSDN here CoInitializeEx Function (COM) there is nothing to indicate it would be a problem. However, whether you can or not is possibly secondary to the question of whether you should or not... why do you need to call CoInitializeEx? Especially as you mention using C#. Plenty of people on this forum use C# injected and called through EndScene hooks, and I know that I've never had to play around with the COM library, and nor have I heard anyone else mention it.

[Edit] Changed link to CoInitializeEx due to mispaste...

[bad6oy30]

My mistake... I thought it was required to inject .net dll's. I found CorBindToRuntimeEx so I'm good. Sorry for the confusion.

I might just stay in c++ anyway

[adaephon]

If you're intending to host .NET 4 you'll need to look at the new interfaces for hosting. CorBindToRuntime(Ex) have been deprecated for CLR4 and beyond, and new interfaces are backwards compatible.

[amadmonk]

I still use the old interface for binding the runtime, since IIRC it's a couple fewer steps. But yeah, it's deprecated so you're probably out of luck if you want to bind with the old call pattern beyond .Net 4.0

[ddebug]

Injecting managed code into an unmanaged process causes lots of headaches if you don't know how to properly marshal stuff. I recommend that you avoid it altogether, if possible.

IMO, just do it in C++ if you have the knowledge to... Save yourself the trouble.

[amadmonk]

Injecting managed code into an unmanaged process causes lots of headaches if you don't know how to properly marshal stuff. I recommend that you avoid it altogether, if possible.

IMO, just do it in C++ if you have the knowledge to... Save yourself the trouble.

?

Having been doing this for... a long time now, I'm not entirely sure what you're getting at.

Managed to unmanaged code marshalling can be tricky, but then again, so can C calling conventions, or smart pointers, or the STL. It's all a matter of what you're familiar with. If you're more productive writing code in a .Net language, then injecting the framework into WoW is the best choice, hands down. In the programming language wars, the winner is ALWAYS "the language you're most familiar with, that can get the job done."

[adaephon]

I still use the old interface for binding the runtime, since IIRC it's a couple fewer steps. But yeah, it's deprecated so you're probably out of luck if you want to bind with the old call pattern beyond .Net 4.0

Using .Net 4? I could never get the old interfaces to work. Either way its not hard. Maybe 5 lines extra