It seems like deployment of VSTO code is very cumbersome.
My use case is I need to enforce a certain content structure in word. Am I better of doing it all in VBA?
+4
A:
It really depends on what makes most sense for your project. If it's only going to be for certain files and a couple users, I would recommend VBA.
If it's more complex and needs to work on all files for all users, I think a VSTO plugin would be the way to go. It really depends on your situation and complexity you're trying to enforce.
Ryan Lanciaux
2008-11-10 20:57:23
caveat about complexity - you can have a large, long running complex app consisting of only a few files and a couple of users that it still requires VSTO over VBA for reasons such as performance.
Anonymous Type
2010-08-30 00:34:48
A:
Keep in mind that it is not only the limitations of VBA as a language, but also the lack of industrial strength tools like unit test frameworks and source control that can be frustrating. You may trade off speed of development with long term frustration because of this if you stick to VBA.
You could do both, writing VBA code to directly support your UI and the rest in .NET.
Andrew Cowenhoven
2008-11-10 21:05:41
Writing solutions that use both is a bad idea. you end up with an overly complex deployment scenario, and the ability for users to break your solution. stick with vsto or vba. mixing is a bad idea.
Anonymous Type
2010-08-30 00:36:17
+2
A:
Before VSTO 3.0 I would agree with Ryan Lanciaux but not anymore. These days I have become so productive in VSTO that I do even small one off jobs in VSTO. That have saved my butt in a few cases as the add-in became very popular within the firm, and all I had to do was to add the path to the Click-once package :-)
Kasper
2008-12-04 20:06:48