4

I want to create a dll which has a managed C++ interface, but the actual code working underneath is native C++.

Currently we are using COM (STA) to interface with the managed code, but now we want to call the module with ThreadPool, which will not allow STA threads. We would like to avoid recoding the module for MTA COM.

I've asked this question before as well as others, and it seems the responses do not address the basic question: how to set up the project. I am using VS2010, and would like the steps laid out. I've tried starting with a managed library (C++ Class Library) and adding unmanaged classes, as well as MFC DLL (we utilize some MFC classes, but would like to work them out eventually) and adding managed classes. I can never seem to get it to compile.

Can someone please humor my ignorance and explicitly lay out the steps starting with the project type?

Deduplicator
  • 44,692
  • 7
  • 66
  • 118
Walter Williams
  • 944
  • 3
  • 11
  • 25

1 Answers1

4

Starting with C++/CLI, Visual Studio no longer produces mixed mode assemblies (like you describe), when compiling. The "native" C++ bits are compiled into nonverifyable CIL.

However, it is possible to embed a static library into your assembly, which is natively compiled, and that native library will be merged in unchanged. That is, if you statically link against a native static library you'll produced the mixed-mode assembly you're looking for.

Billy ONeal
  • 104,103
  • 58
  • 317
  • 552
  • 2
    It's possible to get a true mixed mode assembly if you link a native static library into a C++/CLI assembly, as long as the native static lib wasn't built with `/GL`. – ildjarn Jun 08 '11 at 19:06
  • @ildjarn: Interesting -- did not know that (+1). However, why would one want to do that? :P – Billy ONeal Jun 08 '11 at 20:32
  • There are certain things the native C++ compiler just optimizes better than the JIT compiler, so it's worth having native code. Heavy floating-point math and SIMD vectorization come to mind. – ildjarn Jun 08 '11 at 20:33
  • @ildjarn: I'm not saying why would you want native code. I'm saying why would you want native code in the *same assembly*. If it's in it's own DLL it can be reused; if you lock it inside a .NET assembly it's pretty much stuck there. – Billy ONeal Jun 08 '11 at 20:54
  • @Billy : Are you asking why one would want to use a static library at all, native or managed? I.e., doesn't the same rationale apply as to native executables using native static libraries? – ildjarn Jun 08 '11 at 20:58
  • @ildjarn: The only reason I know of to use a static library is to allow single binary XCOPY deployment. You can't do that using .NET anyway (the runtime must be installed first), so I see little reason to do it for a mixed mode assembly. – Billy ONeal Jun 08 '11 at 22:09
  • @Billy : I doubt I have any rationale that will satisfy you sufficiently, but that's beside the point anyway -- the point that it's possible to create a truly mixed-mode assembly, you don't _have_ to use a separate .dll. – ildjarn Jun 08 '11 at 22:38
  • @ildjarn: I'm confused... didn't we already agree there? :) I just don't think there's a sane reason to ever do it. – Billy ONeal Jun 08 '11 at 23:09
  • @Billy : I never claimed there was; I'm simply trying to point out the inaccuracy in your answer. Claiming something isn't possible is not the same as claiming something is possible but (subjectively) pointless. – ildjarn Jun 08 '11 at 23:31
  • @ildjarn: Ah... I see what you mean. I'm not thinking of that as a comment -- I'm just trying to learn why someone might do that. (In otherwords, I'm curious as to the "unsatisfying rationale") I fixed the answer now. – Billy ONeal Jun 08 '11 at 23:38
  • @Billy : To be honest, I don't know that there's any advantage or disadvantage to linking in a native static lib vs. using a .dll, it just seems like a matter of personal preference. I.e., if there's a strong compelling reason, I don't know what it is either. :-] – ildjarn Jun 08 '11 at 23:55