Visual Basic for Applicationsにはもう将来性がない。今でもOfficeに搭載されているし熱心なユーザには広く人気があるが、VBAを使った開発はなくなりつつある。いつか、Visual Studio Tools for Applications (VSTA)がVBAに取って代わられるだろうが、今のところ注目されていない。MSDN上のポータルもなくなってしまい、たまにブログに話題がのぼるだけだ。
Officeベースの製品に.NETの力を利用したいと思っている開発者には、Visual Studio Tools for Office (VSTO)を使うという選択肢が残っている。VSTOのプロジェクトは、Officeドキュメントに埋め込まれるのではなく、Officeとは分離している。したがって、普通のDLLにコンパイルできるし、クリックワンスやMSIを使って配置もできる。複数のドキュメントで共有するのも簡単だ。
しかし、VBAの熱心なユーザのほとんどはVB.NETやC#のようなコンパイル言語で開発したいと思わないだろう。同じように、会社のすべてのVBAリソースを書き直したいとも思わない。そのリソースが熱心なユーザによってメンテナンスされていればなおさらだ。VSTOとVBAの相互運用性は、今後数年のうちに死活問題となるだろう。
Beth Massi氏が説明するようにVBAとVSTOを統合するにはふたつの方法がある。最も簡単なのはApplication.Runメソッドを使ってVSTOからVBAのマクロを呼ぶ方法だ。しかし、この方法だとマクロは名前で特定されるので、マクロがなかったり単にマクロ名が間違っていても実行時までわからない。
Beth Massi氏が説明する2番目の方法VBAマクロからVSTOのコードを呼ぶ方法だ。ただし呼び出しを行う前に、EnableVbaCallersプロパティをセットしておかなければならない。このプロパティをセットするとVSTOのコードがCOM interoptとして登録される。そしてその後、GetManagedClassのファンクションを使ってVSTOのメソッドや公開プロパティにアクセスすることができる。
Beth Massi氏のブログにはExcelを使って場合のこのふたつのシナリオの検証が記載されている。