In writing performant code in something .Net to work with Excel, one is pretty much obliged to use some form of .Net - Excel bridge. And no, I'm not going through Steve Dalton's book or the Excel 97 SDK manual to use 10-year old technology however stable it may be. Yes, I know there are other ways, but if you want to do lots of calls to CPU-intensive functions, it's probably the way to go - although I'm sure Mark Joshi or Cuchulainn (or even DCFC) might have something to say about this !The 2 big players seem to be ManagedXLL (which is not free) and the open-source ExcelDNA (which is free). I've seen comparisons on the web from 2006, but a time lag of over 2 years is not hugely encouraging as current information - it was suggested that ExcelDNA is not as ruch functionally as ManagedXLL - particularly regarding asynchronous calls.Has anyone done any kind of recent head-to-head comparison of these 2 bridges and come up with any major conclusions ?

my vote is for ExcelDNA. there is not much you can do in terms of performance when crossing the managed/unmanaged boundary and i think they both work the same way- an unmanaged shim with an assembly loader. you might want to try Add-in Expresssee if that works for you its more extensive -- offering you com add-in and RTD support in addition to XLL. price is more reasonable than managedxll especially given the support is fuller.

try www.excel4net.com

the next version of xlw will do .net. See the xlw thread.

Full disclosure: I'm the developer of ExcelDna. (http://exceldna.codeplex.com and http://groups.google.com/group/exceldna)I don't know of any serious performance comparison between ExcelDna and ManagedXll. However, I'd be very interested and surprised if there was a significant performance difference between the two. I'm quite sure that the core unmanaged -> managed transitions are similar. Perhaps the marshaling and memory management of strings or large arrays leaves some scope for differentiation, but I would be happy to help optimize any scenario where ManagedXll outperforms ExcelDna. While calling managed code does has some fixed per-call overhead, it is tiny - some tens of CPU instructions - so you can easily make 300 000 managed UDF calls per second. I have some basic performance info for ExcelDna here: http://exceldna.codeplex.com/Wiki/View. ... ance.While I have never heard of any ExcelDna user having performance issues, there are certainly features that ManagedXll has, which users would love to see in ExcelDna. Some of these might be quite helpful in high-performance scenarios, particularly the RTD and async support, and their multi-threading features. As ExcelDna improves over the next few years, I think most of these features will eventually get added. Most of these would be built in managed code as part of your add-in on top of the core ExcelDna library. But if you need the features now, ManagedXll is worth a look.ExcelDna has an active user community - check the Google group and the ExcelDnaContrib project on CodePlex. Oh, and like you said, ExcelDna is free.

You don't need ExcelDNA nor ManagedXll to write C# based Excel AddIn. You can do it natively in C#. If you worry about performance, integrate C# with standard C++ (or whatever your existing C++ analytic libraries). Alternatively, you can also use C# to write distributed applications.I have done both approaches.