Old Tech Rules

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.

6 Responses to “Old Tech Rules”

  1. Gabriel Says:

    The worst part is supporting multiple versions of Excel… I had to do an add-in that required support of 2000 and 2003 and it was a nightmare to find which combination of the PIAs/VSTO would work on both versions.

    I agree with you on this 100%…

  2. Semper Augustus Says:

    I was somewhat disappointed to find that there are still parts of .Net that are just glorified wrappers around unmanaged code- System.DirectoryServices (maybe it was fixed in 3.5?) was just a wrapper around the already finicky ADSI, VSTO is just a wrapper around the old Office COM API, etc. It just seems like MS hasn’t really tried to fix what it did half-heartedly in the past, but instead has been moving in some really weird directions (use ADO.Net! wait, typed datasets are the answer! no, wait, LINQ to MS SQL Server is the answer! Or the ADO.Net Entity Framework! No, forget that, learn Azure!) (unless you use a database other than SQL Server, than forget all of that silliness…)

    Maybe I’m just cynical, but it’s getting easier and easier to dismiss the “hot new thing” after seeing the chains of poorly thought out products. It’s hard to get excited over Silverlight after seeing Liquid Motion -> ActiveX Controls -> ActiveX Documents (remember those from Visual Studio 6?) -> Silverlight…

  3. Mark D'Agosta Says:

    Dan,

    Thanks for posting this. Visual Studio Tools for Office is a technology that I had great hopes for a few years back, but the public information was always very sketchy. It seemed they really didn’t have all the gears grinding in the same direction. As if they really didn’t want to sell the product.

    I’ve done an extensive amount of Excel/VBA development over the past 5 years but, fortunately, had chucked the VSTO idea in the dustbin. I’m glad I did. Nothing more frustrating that getting hung up on (what should be) a procedural technicality. It’s good to finally hear a review from someone that I consider to be a reliable source.

    BTW, I still consider your book “Developing ActiveX Components with Visual Basic” to be the gold standard of developer books. I never got so much value out of any other book I’ve ever purchased.

    Regards,
    Mark

  4. Michael Dudley Says:

    Wow,
    What perfect timing to read this. I have been developing Excel adins in VBA for a couple of years now and have been able to pull off some really great applications. I have been planning on learning VB.net this summer, possibley start learning C# and to dive into VSTO. Maybe I should rethink this move.

    I have been perferctly happy with VBA, I just have a nagging feeling that the technology bus is leaving me behind as everything moves to .net.

    Should I still be pursuing .net as an office developer?

  5. Matt Says:

    Mr. A., you do know that you are a sort of VB demi-god. If it has to do with VB, if you can’t answer it, it probably doesn’t have an answer, or so it is said. So it’s nice to see that yet even you still get burned by Msoft from time to time. Misery loves company! 🙂

  6. Ernesto Moyes Says:

    Hello, I came across this blog article while looking for help with Microsoft Silverlight. I’ve recently changed browsers from Chrome to Firefox 3.2. Just recently I seem to have a issue with loading sites that use Microsoft Silverlight. Every time I go on a website that needs Microsoft Silverlight, my browser does not load and I get a “npctrl.dll” error. I cannot seem to find out how to fix it. Any aid getting Microsoft Silverlight to function is greatly appreciated! Thanks

Leave a Reply

Comments are moderated - allow 24-48 hours for your comment to appear.