問題描述
在 Office 2007 應用程序中使用 VBA？ (Use VBA in Office 2007 Applications?)
VBA 是否會像 VB6 一樣很快消失？我不應該使用 VBA 開發新的 Office 應用程序嗎？還是我應該使用 VSTO 開發所有新的 Office 應用程序？
更新：最近閱讀此 文章。
參考解法
方法 1:
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.
方法 2:
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.
方法 3:
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.
方法 4:
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.
方法 5:
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).
(by Taptronic、cori、Joe、Guy Starbuck、Richard Gadsden、Ben Hoffstein)