> Speed to market is important too; if you can't get something
> out before your competitors or before another technology
> is available, how fast your code is is irrelevant.
The program is approximately finished, but it is too slow. I'm trying to optimize it now.
> There's always caveats and we can't possibly know all of your
> details, but unless you've got a COM interface to your C++
> code already I don't see a need to go that route.
I have 2 COM interfaces defined in C++ for use by the C# code. I have numerous COM
interfaces defined in C# for the C++ code. I am willing to change all of them if it will
make a difference.
> You mention you've got native code that simply
> can't be made managed; for that COM might be an option;
> especially if you want to use that from other code that
> may be native. COM is similar to IJW in that you don't
> have to manually create the data types on the
> managed side.
As you see above, I don't have a huge issue with interfaces to native code. In fact, I
don't need any native to native API's.
> If you want a physical separation of
> binaries COM might also be a better choice.
One of my C++ methods must be a separate DLL. I have no other requirements.
> I don't think it was mentioned but the
> IJW/C++Interop routes assumes the native code is contained within the
> managed assembly. So, if you do need to reuse the native code, even
> temporarily, IJW might be more work than is necessary (i.e. writing a
> native wrapper to the DLL that your managed wrapper would communicate
> with, two wrappers...).
I'm not certain a native wrapper would be needed. Maybe I can have a managed-only wrapper.
Your message seems to provide suggestions on how to call from managed to native, when in
fact the current issue is how to call from native to managed. I figure somehow I need to
compile some of my C++ code as managed, but I'm not clear on how to make that work given the
need to also connect to native code.