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

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

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

优点：

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

缺点：

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

评论：

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