I added a new DLL to my product so that I can call a coworker's C# code to
parse an XML file he creates using the same source code. I isolated all Dot
Net changes (I thought) to a single function in a single file that calls the
DLL, so I expected (foolishly?) that if there were any price to be paid for
calling C# and crossing the Dot Net / unmanaged boundary I should only have
to pay it when I call that one function.

Much to my surprise, I found a few inline functions that seem to run as much
as 28x slower!! And some inline functions will no longer allow me to set
breakpoints in them (and they used to in the last release before I added Dot
Net support).

If I move a single inline constructor into another file and remove the
“inline”, that seems to fix the speed slowdown. If I restore the compiler
settings back to unmanaged on the one file that calls Dot Net (and gut the
call to the DLL), that seems to fix it too, although that's not a long term
solution.

Changing the one constructor to not be inline is a perfectly acceptable
solution, but it scares the hell out of me that such a side effect would
exist at all. I’m worried that there are other such side effects that are
lurking that I just haven’t tripped over yet.

In an unrelated(?) issue, I also ran into some Ole/COM-related issues where
a Microsoft OCX control I use expects Ole to be initialized as STA (single
threaded apartment model), but if the managed code gets there first it
initializes things as MTA (multithreaded apartment model) which causes the
control to crash. I’ve got that “fixed” by making sure to initialize Ole to
STA very early in the app, but again I worry about other bizarre unknown side
effects.

Anybody have any suggestions?