在 Office 2007 应用程序中使用 VBA？
VBA 会像 VB6 一样很快就会消失吗？ 我不应该使用 VBA 开发新的 Office 应用程序吗？ 或者我应该使用 VSTO 开发所有新的 Office 应用程序？
更新：最近阅读了这篇文章。
Is VBA going to go away any time soon, like VB6 has? Should I not develop new Office applications with VBA? Or should I be developing all new Office Apps with VSTO?
Update: Recently read this article.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
这是来自 Microsoft 的评论 关于未来的 VBA 支持。 简而言之，它不会在 Windows 版本的 Office 上消失（但在 Mac 版本上已停止）。
Here is a comment from Microsoft regarding future VBA support. In a nutshell, it is not going away on Windows versions of Office (but is discontinued for Mac versions).
VBA 距离贬值还有很长的路要走，事实上 VBA 将被重新引入到 MAC 上的下一版本 Office 中（ http://www.microsoft.com/presspass/press/2008/may08/05-13MacBU2008PR.mspx)。
对于大多数人来说，VBA 和 C XLL（以及 VB6！！）仍然是首选工具。 当前的 .NET 链接速度很慢，并且生产率增益为零。 ExcelDNA 等第三部分工具在一定程度上缓解了这种痛苦，但显然，基于非托管 C（和基于汇编程序）的 Office 代码库并不容易与 .NET 兼容。
VBA is a long way from being depreciated, in fact VBA is to be reintroduced into the next version of Office on the MAC ( http://www.microsoft.com/presspass/press/2008/may08/05-13MacBU2008PR.mspx).
For most people on the ground, VBA and C XLLs (and VB6!!) continue to be the tools of choice. The current .NET linkages are slow and offer zero productivity gain. 3rd part tools such as ExcelDNA ease the pain somewhat but obviously the unmanaged C based (and assembler based) code base of Office doesn't sit easily with .NET.
VSTO有新的功能，但与VBA相比也有一些重大缺陷。
一方面，代码访问安全性可能会使部署 VSTO 应用程序变得困难（这是礼貌的说法）。
另一方面，VSTO 开发环境远不如 VBA 那样可供“高级用户”开发人员使用。 例如，没有宏记录器可以帮助您入门。
一个重大问题是 .NET 与进程外 COM 对象的互操作效果不佳。 例如，如果您想要从 Excel VSTO 应用程序中操作其他 Office 应用程序（Word、PowerPoint、Outlook），您会发现这些应用程序的多个副本在后台运行，原因请参见 此知识库文章。
所有这些加上对现有 VBA 应用程序的巨额投资意味着 VBA 不会很快消失。
VSTO has new features, but also has a number of major deficiencies compared with VBA.
For one thing, Code Access Security can make it difficult to deploy VSTO applications (that's being polite).
For another, the VSTO development environment is nowhere near as accessible to "Power User" developers as VBA. For example, no macro recorder to get you started.
And a big showstopper is that .NET interop with out-of-process COM objects doesn't work well. For example, if you want to manipulate other Office applications (Word, PowerPoint, Outlook) from within an Excel VSTO application, you will find multiple copies of these applications running in the background, for the reasons described in this KB article.
All this coupled with the huge investment in existing VBA apps means VBA won't be going away any time soon.
Office VSTO 比 Office VBA 提供了大量附加功能，虽然我不相信 Microsoft 已表示将终止 VBA（事实上，他们明确表示它将至少持续到 Office 14；Office 2007 = Office 12） ，我认为将应用程序迁移到 VSTO 以利用额外的灵活性和功能是非常值得的。
实际上，我认为弃用 VBA 是不可行的，因为相当多的 Office 编程是由企业用户在宏观层面上进行的，而且我认为这种情况不会很快消失。 这些人通常无法访问支持 VSTO 的 IDE。
Office VSTO offers a great deal of additional functionality over Office VBA, and while I don't believe Microsoft has signaled that it's going to terminate VBA (in fact, they've said explicitly that it will be around at least until Office 14; Office 2007 = Office 12), I think it's well worth the effort to move your applications to VSTO to take advantage of the additional flexibility and power.
I actually don't think that deprecating VBA would be feasible, since a fair amount of Office programming takes place at the macro level by business users and I don't think that's going to go away any time soon. Those folks don't generally have access to a VSTO-capable IDE.
Microsoft 已声明 将支持 VBA 在可预见的未来继续前进，但他们也建议新应用程序使用 VSTO。
最新的Mac版本的MS Office不支持VBA，64位Windows以虚拟32位进程外模式运行它。 因此，如果您正在计划使用 Office 作为平台的新应用程序，VSTO绝对是最佳选择，但您不必太担心旧版支持。
正如 @cori 指出的那样，对于微软来说，仅仅取消支持并破坏如此多的现有软件将是一个很大的营销禁忌。
Microsoft has stated that VBA will be supported moving forward for the forseeable future, but they are also recommending that new apps use VSTO.
The latest Mac version of MS Office don't support VBA, and 64-bit Windows runs it in a virtual 32-bit out-of-process mode. So if you are planning a new application using Office as a platform, VSTO is definitely the way to go, but you shouldn't worry too much about legacy support.
As @cori points out, it would be a big marketing no-no for MS to just yank support and break so much existing software.
自从 .NET 首次发布以来，微软一直在暗示 Office 的托管代码版本具有集成的 VSTO（大概与 VB6 IDE 与 VBA 集成的方式相同，因此 VS IDE 将与 VSTO 集成）。
考虑到涉及的编码量——并且考虑到这不会产生任何用户可见的功能——我非常怀疑这在微软优先级列表中是否处于高位。 我可以想象他们在现有代码库的顶部分层了一组托管对象代码（就像 Joel Spolsky 在首先将 VBA 放入 Excel 时在现有的 C 代码库上分层了一组 COM 对象一样），并创建了一个新的 IDE作为默认值，同时隐藏旧的。 即使这将是一个主要的练习（想象一下编写宏记录器！）。 当然，这将使 .NET 成为 Office 的先决条件，而 Office 团队只有在枪口下才会接受。
当然，他们永远不会真正从产品中删除 VBA - Excel 仍然支持 Excel 4 宏，Word 仍然具有 WordBasic Automation 对象来支持 Word 6 宏，并且没有迹象表明其中任何一个被删除，因为有太多的内容。要支持遗留代码 - 十年来没有人使用过这些编码模型中的任何一种。
如果 Microsoft 确实将 .NET 环境引入 Office（坦率地说，我怀疑这是否会发生），那么他们可能会停止添加对新 Office 功能的 VBA 支持。 这是他们最接近停止使用 VBA 的情况。
Microsoft have been dropping hints at a managed-code version of Office with an integrated VSTO (presumably in the same way as the VB6 IDE is integrated for VBA, so the VS IDE would be integrated for VSTO) ever since .NET was first released.
Given just how much coding is involved - and given that this would not produce any features that would be visible to users - I very much doubt that this is high on the Microsoft priority list. I can imagine that they layer a managed code set of objects over the top of the existing codebase (much as Joel Spolsky layered a set of COM objects over the existing C codebase when putting VBA into Excel in the first place) and bung a new IDE in as the default, while hiding the old one. Even that would be a major exercise (imagine writing the macro recorder!). Of course, this would make .NET a pre-req for Office, which the Office team will only accept at gunpoint.
They will never actually remove VBA from the products, of course - Excel still supports Excel 4 macros, and Word still has the WordBasic Automation object to support Word 6 macros, and there's no sign of either of those being removed, since there is too much legacy code to support - and no-one has used either of those coding models in a decade.
If Microsoft do ever put a .NET environment into Office (which, frankly, I doubt will ever happen), then they might stop adding VBA support for new Office features. That's the closest they'll get to discontinuing VBA.
VBA插件部署起来有点麻烦，但VSTO更是如此。 此外，VSTO 涉及一些开销，因为它需要在运行代码之前启动 CLR。
但最重要的是； VSTO 消除了编写 VBA 的痛苦。
VBA add-ins are a bit troublesome to deploy, but VSTO is even more so. Also, VSTO involves a bit of overhead, as it needs to start up the CLR before running your code.
But most important of all; VSTO takes away the pain of writing VBA.