MS Word 可扩展性：VBA 宏与 .Net VSTO？答案

【问题标题】：MS Word extensibility: VBA macro versus .Net VSTO?MS Word 可扩展性：VBA 宏与 .Net VSTO？
【发布时间】：2011-11-29 18:06:24
【问题描述】：

我的一位客户要求我们开发“VBA 宏”。然而，在 2010 年代，我仍然使用这种过时的语言似乎很奇怪，我正在考虑尝试说服客户改用 VSTO dev。但是，由于我是两个世界的新手，我需要帮助来填写一个赞成/反对页面才能对此进行辩论。

当然，没有实际需求也不能得到答案，让我尝试恢复：

目标：Word 2003/2007（但我怀疑 2010 年是一个未知的要求）编辑 2010 年要求已确认

外部发布系统需要 .doc 文件作为输入。 .doc 文件必须应用一些特定的样式：“自定义页眉 1”、“自定义页眉 2”等。

用户可以通过两种可能的方式使用 Word 构建文档：

使用部署在计算机上的 .dot 文件启动新文档

转换任何现有文档以匹配目标模板

用户可以“简单”地“应用”样式（简单的 UI）：上下文菜单、样式菜单、自定义操作窗格等。

到目前为止，我看到以下优点/缺点：

VBA
- 优点：
  - ?
  - 快速而肮脏的发展（句子的快速部分）
  - 客户已经有一些在生产宏
- 缺点：
  - 很难找到熟练的开发人员
  - 快速而肮脏的发展（句子的肮脏部分）
VSTO
- 优点：
  - .Net 语言的好处（编译、类型化、严谨、类库等）
  - 更灵活、更强大的安全模型（由受信任机构签署的信任代码）
  - 可以连接到 WPF 窗格
  - 您在 Visual Studio 中工作并可以使用其全套功能：重构、源代码控制等。
- 缺点：
  - 需要安装 .Net 框架（现在可能不是问题）和 VSTO 运行时
  - 更难部署
  - 一开始的工作量会稍微多一些（但从长远来看会少一些）

【问题讨论】：

标签： vba ms-office vsto

【解决方案1】：

我对 .NET 不够熟悉，但以下是我对 VBA 的拙见：

VBA

优点：
- 易于部署并使其与 Office 应用程序配合使用
- 快速而肮脏的发展（句子的快速部分）-同意
缺点：
- ~~很难找到熟练的开发人员~~
- 很难选择熟练的开发人员并向您的客户解释他需要投资这项技能
- 快速而肮脏的发展（句子的肮脏部分）-部分同意。如果出现以下情况，它将很脏：
  - 您将项目交给 VBA 初学者，而不是陷害他/她
  - 就要求而言，您的项目太大
- ~~需要安装 .Net 框架（今天可能不是问题）~~ 我不这么认为（可能是 VSTO 的缺点？）

我想说，如果你只想有一些代码或插件来合并一些样式，你可以很容易地用 VBA 做到这一点而且它不会很脏（除非你真的想要它到）。

【讨论】：

你是对的...... con“需要安装 .net 框架”与 vsto 相关，而不是 VBA
我认为对于管理模板等简单的事情，VBA 可能是要走的路。当项目不再是您关心的问题时，熟练的用户甚至可以进行细微的更改，@Steve，这对客户来说必须是一个优势。
我认为这也取决于业务规则的复杂性。它们中的大多数将包括解析现有文本以查找§ starting with x. will be cust head style 1, § starting with x.Y will be cust head style 2, and so on 之类的模式+ 一些错误检查。
@SteveB：我真的认为这可以在 VBA 中完成而不会带来太多痛苦。然而，我不知道 VSTO 中的性能是否比纯 VBA 更好。
我担心这种要求的性能是否会成为 VBA 和 VSTO 世界之间的区别点:)

【解决方案2】：

我是一名重度 Excel VBA 开发人员。

VBA 专业版：我从 VBA 切换到 VSTO 的主要障碍之一——相信我，我喜欢 C# 编码——没有我的用户群已经习惯的动态调试。当它发生时，我经常直接跳入用户 PC 上的 VBA 问题，但使用 VSTO，这是不可能的。（除非有人能纠正我。）

如果您的用户没有这样的期望，那么您可能很容易没有这种期望。

VBA 缺点： VBA 是一种易于使用的语言，因此很容易弄乱。它不强制执行“干净的编码”原则，这意味着虽然体面的程序员可以使用它们制作出色的应用程序，但由于入门门槛低，VBA 可以与 hackjobs 和庞大的有机代码相关联。由于这个原因，VBA 开发人员通常被认为是较低级别的开发人员，而实际上无法区分那些明智地使用它的人和不明智地使用它的人。

我怀疑是否有人选择 VBA 作为他们选择的职业语言，这只是发生在他们身上。除了很难找到熟练的开发人员之外，过多的 VBA 工作可能会拒绝潜在的员工，因为他们不想与“另一个不受管理的 VBA 蔓延的泥潭”相关联。有些人使用 VBA 来说明您对技术有多“认真”。

（我倾向于以同样的方式看待 Perl；非常适合短脚本，但当习惯用于脚本的人开始使用更大的工作时 - 您往往会得到一些有点笨拙的东西。）

【讨论】：

【解决方案3】：

随着项目的完成，我正在回答自己的问题。

我最终决定使用 VBA 宏来编写应用程序。这是这个选择的事后结论：

优点：

将维护应用程序的团队没有 C# 知识，只有 VBA（我选择的主要原因）。
安全模型差：它是专业的，因为没有其他设置可以将文件放在正确的位置。
没有运行时先决条件

缺点：

部署应该很简单。
- 我正在考虑使用 Word 选项“用户模板目录”和“启动模板目录”的可能性。但这是不可能的，因为该应用程序与客户组织中的特定实体无关。我不被允许“拥有”此应用程序的设置。
- 我最终编写了一个自定义 NSIS 脚本，以将应用程序部署到正确的文件夹中。使用 VSTO，一个简单的设置项目（clickonce？）就可以完成这项工作。
语言是如此史前！集合索引从 1 开始，数组从 0 开始，没有 OOP，开箱即用的语言和库功能很差。这并不总是一个问题，但就我而言，对业务规则进行建模有点痛苦（在树中表示分层数据并非易事）
与源代码管理的集成非常有限（代码，因为它嵌入在 .dot 文件中，无法历史记录。只有完整的 .dot 是）
VBA 的错误管理非常有限
IDE 很差

备注：

作为一名经验丰富的 C# 开发人员，优点/缺点可能有点偏。

【讨论】：

【解决方案4】：

在这个article 中，我试图在 Excel 的上下文中总结类似的问题。相同的参数适用于包括 word 在内的所有 Office 应用程序。

【讨论】：

【解决方案5】：

根据我的观察： VSTO：缺点：如果我们为 word 2007 开发了插件功能区控件，我们只能使用 word 2007 部署，但我们不能使用 word 2010 或 word 2013 部署。这是我为 word 和 2007、2010 和 2013 等所有版本开发插件的主要缺点。如果有错请纠正我或建议我如何为所有办公版本开发单一插件。

【讨论】：