Skip the text and just notice that I do have nice formulas like this: =NxRead(“server”,”file,id,atb,val,sv”,”options”).

Then notice the screenshot of the Database Explorer I built into Excel, plus toolbar buttons, etc.

All of that was done with a great product called Add-in Express http://www.add-in-express.com/. I can’t say enough good things about the software, people, and community for that line of products (without drooling on my keyboard). Their helper libraries saved me from all the pains documented in this blog – but by the time I got to savor the tasty goodness of success I had to move on to other business, and I never got to publish that offering. Perhaps one of these days I’ll get a chance.

I strongly encourage Microsoft Office developers to get familiar with the Add-in Express offerings. The documentation might leave you wondering where you separate VSTO from their components, when you need either or both. But the answers are out there, at least you have a choice, and success is on the other side. Just looking at the screenshots you can see some great things done with Excel. End-users look at that and think “I expect this of Excel” but developers like us recognize the pain required to make it all happen, and wonder if it’s even possible outside of Redmond. That pain was eliminated with Add-in Express. (End unintentional and unpaid marketing speech.)

I hope I can find some time just to blog about Add-in Express, which I used successfully for both Excel and IE integration, but unfortunately not for anything for sale yet. Good luck!

Great work on this series… wish I had found your blog sooner, it would have saved me a world of hurt!!

I realize that a couple years have past since the last update here, but nevertheless its still pretty relevant stuff, disappointingly very little has been done by Microsoft to make this diabolical process easier.

I have spent the last two weeks on getting my automation add-in right, I now have my solution, even though I am still working out all the kinks in production, but at least I have successfully deployed.

I went the route of VSTO with two assemblies (I noticed you wrote about this option somewhere but hadn’t explored it), this was incidental though, had I seen your blog I might have taken a different route… the idea is that they are both COM Visible, strong name signed and the Assembly with my UDF Class implements IDTExtensibility2 with the difference being that it is registered for COM Interoperability… I have to run regasm /codebase it seems on both dll’s after installing and only then does it work. I have seen some Microsoft bug reports about this, that the types don’t get registered correctly unless you explicitly do this.

I am not well versed yet with all of the semantics, VSTO and COM are new to me, but I appears I can get a reference to the Excel application using IDExtensibility2, it seems to be the same instance as well but my managed VSTO code resides in another AppDomain so I simply marshal the objects I need using domain.CreateInstanceAndUnwrap, and those objects extend MarshalByRefObject and are serializable so interoperability is quite seamless.

People suggest performance is not ideal with this approach, but I disagree, its certainly acceptable (they run within the same process for goodness sake) I find its pretty fast (even close to instant), and if you design it well even better.

I am using the VSTO managed code to preload some large datasets, and they don’t get too much larger than the ones I have, which I indecently fetch using SOAP Web services, native SQL will be even faster, and these DataSets can even be cached now.

I didn’t go the shim route, in theory that does look like a better option from reading your blog, nevertheless I thought I would share my alternative approach that seems to do the job, being slightly simpler to implement and deploy.

Cheers!
Peter