Why Visual Tools for Office?

The forthcoming release of Visual Studio Tools for Office, begs the question - why not include .NET runtime scripting in Office? What about VSA?

In response to a post on the Windows-Script MSN group this week regarding the state of .NET scripting, I wrote...

"Scripting in .NET has been undergoing something of a crisis. Architectural issues prevent either a VSA or a CodeDom based scripting solution from offering effective "integration" scripting at run-time. Integration scripting provides for customization of program functionality by providing access to live objects and events.

Additionally, despite being initially advertised as the .NET replacement for VBA, VSA is currently only suited to a scenario where customization is performed at design-time rather than at run-time. For example, it's suited to a web-based application that offers end-user customization at time of setup.

I believe this limitation to be the reason that Office 11 continues to support VBA and only provides .NET extensibility through Visual Studio.NET at design time or the Office PIA's.

However, .NET is ideal for administrative scripting due to the depth and breadth of the Framework Class Library (FCL) and the productivity of the languages."

No Comments