Question

One of my customers asked us to develop a "VBA macro". However, in the 2010s, it seems weird to me to still use such outdated language, and I’m thinking about trying to convince the customer to use VSTO dev instead. However, as I’m new to both worlds, I need help to fill a pro/cons page to be able to argue this.

Of course, the answer can’t come without the actual requirement, let me try to resume:

Target : Word 2003/2007 (but I’m suspecting 2010 as a not yet known requirement) edit 2010 requirement confirmed

An external publishing system requires .doc file as input. The .doc file must have some specific styles applied : "Custom Header 1", "Custom header 2", etc.

The user can build documents, using Word, using two possible ways:

1. Start the new document using a .dot file deployed on the computer
2. Transform any existing document to match the target template

Users can "apply" the styles "simply" (simple UI): context menu, styles menu, custom action pane, etc.

By now, I see the following pro/cons:

1. VBA

   • Pros:
     • ?
     • quick and dirty development (quick part of the sentence)
     • The customer has already some in production macro
   • Cons:
     • hard to find skilled developer
     • quick and dirty development (dirty part of the sentence)

2. VSTO

   • Pros:
     • benefits of the .Net language (compiled, typed, rigorous, class library, etc.)
     • security model more flexible and powerful (trusting code signed with a trusted authority)
     • bridge to WPF panes possible
     • You work in Visual Studio and have access to its full set of features: refactoring, source control, etc.
   • Cons:
     • requires installation of the .Net framework (probably not an issue today) and VSTO runtime
     • harder to deploy
     • slightly more work at the start (but less in long term)

Answer 1

I’m answering myself to the question, as the project is finished.

I finally decided to write the application using a VBA macro. Here is the post-mortem conclusion of this choice :

Pros:

1. The team that will maintains the application has no C# knowledge, only VBA (main reason of my choice).
2. Poor security model : it’s a pro because there is no other setup that putting the files in the right place.
3. No runtime prerequisites

Cons:

1. The deployment was supposed to be simple.
   • I was counting of the possibility to play with Word options “User-template directory” and “Startup template directory”. But it wasn’t possible, because the app is not related to a specific entity in the customer organisation. I wasn’t allowed to “take ownership” of this settings for this application.
   • I ended in writing a custom NSIS script to deploy the application on the correct folders. With VSTO, a simple setup project (clickonce?) would have done the job.
2. The language is so prehistoric ! Collections index starts to 1, array to 0, no OOP, poor out-of-the box language and library feature. That is not always a problem, but in my case, modeling the business rule was a bit painful (representing hierarchical data in a tree was not an easy job)
3. Very limited integration with source control (code, as it’s embeded in the .dot files, was not historisable. Only the full .dot was)
4. Error management very limited with VBA
5. Poor IDE

Remark:

As an experienced C# developer, the pros/cons may be partial a bit.