VBA是否会像VB6一样很快消失？我不应该使用VBA开发新的Office应用程序吗？还是应该使用VSTO开发所有新的Office Apps？

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

解决方案

Office VSTO提供了比Office VBA更多的添加功能，尽管我不相信微软已经暗示要终止VBA(事实上，他们明确表示至少要等到Office 14; Office才可以)。 2007 = Office 12)，我认为将应用程序迁移到VSTO来利用额外的灵活性和强大功能是值得的。

实际上，我认为弃用VBA是不可行的，因为商业用户在宏级别上进行了大量的Office编程，而且我认为这种情况不会很快消失。这些人通常无法访问具有VSTO功能的IDE。

这是Microsoft关于将来VBA支持的评论。简而言之，它在Windows版本的Office上并没有消失(但在Mac版本中已停产)。

Microsoft已声明在可预见的将来将支持VBA，但他们也建议新应用程序使用VSTO。

最新的Mac版本的MS Office不支持VBA，并且64位Windows在虚拟32位进程外模式下运行它。因此，如果我们打算使用Office作为平台来计划一个新的应用程序，那么VSTO无疑是必经之路，但是我们不必太担心传统支持。

正如@cori指出的那样，MS仅仅依靠技术支持并破坏很多现有软件将是巨大的营销禁忌。

VBA距离折旧还有很长的路要走，实际上VBA将重新引入到Mac上的Office的下一版本(http://www.microsoft.com/presspass/press/2008/may08/05-13MacBU2008PR.mspx) 。

对于大多数在地人员来说，VBA和C XLL(以及VB6 !!)仍然是首选工具。当前的.NET链接速度很慢，并且生产率提高为零。第三部分工具(例如ExcelDNA)可以减轻一定的痛苦，但是显然，.NET不能很好地解决Office的不受管理的基于C(和基于汇编程序)的代码库的问题。

VSTO具有新功能，但与VBA相比，还具有许多主要缺陷。

一方面，代码访问安全性可能使部署VSTO应用程序变得困难(这是礼貌的)。

另一方面，"高级用户"开发人员无法像VBA那样轻松地访问VSTO开发环境。例如，没有宏记录器可以入门。

最主要的问题是，与进程外COM对象的.NET互操作性不好。例如，如果我们要从Excel VSTO应用程序中操纵其他Office应用程序(Word，PowerPoint，Outlook)，则由于此知识库文章中所述的原因，我们会发现这些应用程序在后台运行的多个副本。

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

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

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

自.NET首次发布以来，Microsoft一直在暗示集成了VSTO的Office的托管代码版本(大概与为VBA集成VB6 IDE相同，因此将为VSTO集成VS IDE)。

考虑到所涉及的编码量很大，并且不会产生任何对用户可见的功能，我非常怀疑这在Microsoft优先级列表中是否很高。我可以想象它们将对象的托管代码集覆盖在现有代码库的顶部(就像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的最接近的方式。