Yesterday I needed to do a simple Excel add-in.
No problem, right?
Being an experienced .NET developer, I figured this would be a good time to try the Visual Studio Office system – to create the add-in using VB .NET. I mean, how hard could it be?
Not hard at all as it turned out. The project template for the add-in worked well, and it took no time at all to find some simple examples online to build on. I had enough familiarity with the Excel object model to make short work of the task at hand, and the integration that allowed debugging of add-ins in Visual Studio worked brilliantly.
Then it came time to test deployment – as I needed to provide this add-in to a couple of clients.
What a fiasco.
The setup project that was created didn’t work. The instructions on MSDN and other sites for diagnosing problems were complex and unreliable. I found additional articles with suggestions for creating custom installation actions to handle the security issues that might have been the problem. There were clearly differences between versions of the Visual Studio office runtimes depending on framework version and versions of Excel to support, with no clear explanation of which to use and how to create a deployment that will work with both.
I spent as much time trying to figure out the deployment as I did creating the add-in when I decided I was wasting my time. The Visual Studio office support may be nice, but the deployment solution and documentation is abysmal. Microsoft should be ashamed to have released it. It is perhaps the most disappointing experience I’ve had with any Microsoft developer technology.
I ended up porting the code to VBA in an Excel workbook and creating a .xla Excel add-in. Though I missed the intellisence of Visual Studio, the building and debugging experience was fine. And deployment was trivial – save the workbook as an add-in. Deployment consisted of browsing to the add-in file and enabling it – and the add-in worked perfectly on Excel 2003 and 2007 the first time I tried it.
I’d come to think of .NET as current technology rather than the wave of the future. It’s clear to me that at least when it comes to Office, .NET is still future technology – costly, complex and unreliable. If I need to do any more Office add-ins, you can bet I’ll stick with VBA.