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

Question

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

当然，没有实际需求就不可能有答案，让我试着恢复一下：

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

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

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

1. 使用计算机上部署的 .dot 文件启动新文档
2. 转换任何现有文档以匹配目标模板

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

现在，我明白了以下优点/缺点：

1. VBA

   • 优点：
     • ？
     • 快速而肮脏的开发（句子的快速部分）
     • 客户已经有一些正在生产的宏
   • 缺点：
     • 很难找到熟练的开发人员
     • 快速而肮脏的开发（句子的肮脏部分）

2. VSTO

   • 优点：
     • .Net 语言的优点（编译、类型化、严谨、类库等）
     • 安全模型更加灵活和强大（信任由可信机构签名的代码）
     • 可以桥接到 WPF 窗格
     • 您使用 Visual Studio 工作并可以使用其全套功能：重构、源代码控制等。
   • 缺点：
     • 需要安装 .Net 框架（今天可能不是问题）和 VSTO 运行时
     • 部署更困难
     • 开始时工作量稍多（但长期来看会减少）

Answer 1

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

VBA

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

我想说，如果你只想有一些代码或加载项来合并一些syles， 你可以轻松地做到这一点VBA 并且它不会被弄脏（除非你真的想要它）。

Answer 2

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

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

优点：

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

缺点：

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

备注：

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

Answer 3

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

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

如果您的用户没有这样的期望，那么您可能可以轻松地生活在没有这样的期望的情况下。

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

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

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

Answer 4

在这篇文章中，我尝试总结类似的问题，在 Excel 上下文中。同样的论点适用于所有 Office 应用程序，包括 Word。

Answer 5

根据我的观察：
维斯托：
缺点：如果我们为word 2007开发了Addins功能区控件，则只能使用word 2007进行部署，而不能使用word 2010或word 2013进行部署。
这是我为 word 和 excel 的所有版本（如 2007、2010 和 2013）开发插件的主要缺点。如果有错，请纠正我，或者建议我如何为所有 Office 版本开发单个插件。