Hi I want some expert/experienced advice on the best approach/method of using C++ code in Excel. For example building some pricing models in C++ and using them in Excel. I know there are various ways so I want your opinion. It seems there are lot of pages on using COM. but I personally think COM is OLD, and UGLY! am I wrong? or is it really still the best option? I know of Excel-DNA and it really is perfect for use with C#, but there really is no similar option for C++ - although I've seen some commercial options, for example: 1 http://www.stochastix.com/solutions/excel/managedxll/latest/features 2. http://www.planatechsolutions.com/xllplus/default.htm Really appreciate your toughts. thanks
Use C++/CLI, and recompile your libraries in that, then connect to whatever .NET bindings that Excel-DNA thing is supporting. And if that's not possible, create an assembly with C++/CLI, wrap it in a C# interface and then connect /that/ to Excel-DNA.
ok - saw I have two different options offered already - but which is better? also have you actually experience doing this? are there any limitations using a dll or going through c# excel-dna? can you use objects exactly the same way etc? ALSO - what if you have lot of code in non-CLI that might be difficult to recompile.. thanks
I've never had any difficulties recompiling native code in C++/CLI, and C++/CLI seems to link in native libraries and automatically generate the wrapper/transition code to get information out of the native libraries properly. I use C++/CLI quite a bit, mostly because using COM libraries or various broker interfaces and changing from broker to broker on all the various prop front-ends always involves some random new hodge-podge of Windows-related technology. C++/CLI is somewhat of a god-send because it serves as a sort of glue for connecting old/native code with systems that use .NET. The added benefit is that you can still write solid, re-usable C++, and not feel bound to .NET forever. I can't comment on Excel-DNA; I've never used it. I was just proposing an alternative if you didn't want to be forced into C#.
if you have c++ dlls already, making a call via win32 is straightforward and would be the fastest way. If you want to abstract things in a pretty manner and don't mind learning cli...go with that route.
thanks for your input - yes I think I'm going to try both and see how it goes. I was playing around with direct dll earlier, but I'm on win64 and it seems there are some data issues around it, don't know if it's the excel version or the os. but will try both. thanks again.