excel - 在 Office 2007 应用程序中使用 VBA？

Question

VBA 会像 V​​B6 一样很快消失吗？我不应该使用 VBA 开发新的 Office 应用程序吗？或者我应该使用 VSTO 开发所有新的 Office 应用程序？

更新：最近读了这篇文章。

Answer 1

Office VSTO 在 Office VBA 上提供了大量附加功能，虽然我不相信微软已经表示它将终止 VBA（事实上，他们已经明确表示它至少会在 Office 14 之前出现；Office 2007 = Office 12），我认为将您的应用程序迁移到 VSTO 以利用额外的灵活性和功能是非常值得的。

实际上，我认为弃用 VBA 是不可行的，因为大量的 Office 编程是由业务用户在宏观层面进行的，而且我认为这种情况不会很快消失。这些人通常无法访问支持 VSTO 的 IDE。

Answer 2

VSTO 有新的特性，但与 VBA 相比也有一些重大的不足。

一方面，代码访问安全性会使部署 VSTO 应用程序变得困难（这是有礼貌的）。

另一方面，对于“高级用户”开发人员而言，VSTO 开发环境远不如 VBA 那样容易访问。例如，没有宏记录器可以帮助您入门。

一个大的亮点是.NET 与进程外 COM 对象的互操作不能很好地工作。例如，如果您想在 Excel VSTO 应用程序中操作其他 Office 应用程序（Word、PowerPoint、Outlook），您会发现这些应用程序的多个副本在后台运行，原因在本知识库文章中描述。

所有这些加上对现有 VBA 应用程序的巨额投资意味着 VBA 不会很快消失。

Answer 3

微软表示在可预见的未来将支持 VBA，但他们也建议新应用程序使用 VSTO。

最新的 Mac 版本的 MS Office 不支持 VBA，64 位 Windows 以虚拟 32 位进程外模式运行它。因此，如果您正在计划使用 Office 作为平台的新应用程序，VSTO绝对是要走的路，但您不必太担心遗留支持。

正如@cori 指出的那样，对于 MS 来说，仅仅取消支持并破坏如此多的现有软件将是一个很大的营销禁忌。

Answer 4

自从 .NET 首次发布以来，Microsoft 一直在暗示带有集成 VSTO 的 Office 托管代码版本（大概与为 VBA 集成 VB6 IDE 的方式相同，因此为 VSTO 集成 VS IDE）。

考虑到涉及多少编码 - 并且考虑到这不会产生任何用户可见的功能 - 我非常怀疑这在 Microsoft 优先级列表中是否很高。我可以想象他们在现有代码库的顶部分层了一组托管代码对象（就像 Joel Spolsky 首先将 VBA 放入 Excel 时在现有 C 代码库上分层了一组 COM 对象）并安装了一个新的 IDE in 作为默认值，同时隐藏旧的。即使那将是一个主要的练习（想象一下编写宏记录器！）。当然，这将使 .NET 成为 Office 的先决条件，Office 团队只会在枪口下接受。

当然，他们永远不会真正从产品中删除 VBA——Excel 仍然支持 Excel 4 宏，Word 仍然具有支持 Word 6 宏的 WordBasic 自动化对象，并且没有任何被删除的迹象，因为有太多要支持的遗留代码 - 十年来没有人使用过这些编码模型中的任何一种。

如果微软确实在 Office 中加入了 .NET 环境（坦率地说，我怀疑这是否会发生），那么他们可能会停止为新的 Office 功能添加 VBA 支持。这是他们最接近停止使用 VBA 的方法。

Answer 5

这是Microsoft关于未来 VBA 支持的评论。简而言之，它不会在 Windows 版本的 Office 上消失（但在 Mac 版本中已停产）。

Answer 6

VBA 离贬值还有很长的路要走，事实上 VBA 将被重新引入 MAC 上的下一版本 Office ( http://www.microsoft.com/presspass/press/2008/may08/05-13MacBU2008PR.mspx ) .

对于现场的大多数人来说，VBA 和 C XLL（以及 VB6 ！！）仍然是首选工具。当前的 .NET 链接速度很慢，并且提供零生产力增益。第 3 部分工具（如 ExcelDNA）在一定程度上减轻了痛苦，但显然基于非托管 C（和基于汇编程序）的 Office 代码库不能轻松地与 .NET 搭配使用。

Answer 7

VBA 加载项部署起来有点麻烦，但 VSTO 更是如此。此外，VSTO 涉及一些开销，因为它需要在运行代码之前启动 CLR。

但最重要的是；VSTO 消除了编写 VBA 的痛苦。