« Home | GoogleReader+Firefox2+TabletPC » | Core 2 Duo bang for your buck » | Viewbox scaling in ElementHost » | EID and Standalone XAML » | ClickOnce Adventures » | Dns.GetHostEntry: No such host is known » | MacroView Studio VNC » | MVS Reports Script Tips » | Delegators mount up! » | AMD Slashing Prices »

VSTO SE links and thoughts

This post is mainly just the noting down of a collection of VSTO (Visual Studio Tools for Office) 2005 SE related links (which then turned into a rant down the track).

Announcement of VSTO 2005 SE on the forums: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=726538&SiteID=1

Useful thread that helped me get what VSTO 2005 SE was about: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=826527&SiteID=1

A quote from that thread that helped:

Here is the confusing part:

App-level solutions built with VSTO2005se are supported on Office 2003 Std and office 2007 Std

Doc-level solutions built with VSTO2005 are only supported on Office 2003 Pro, Office 2003 Word standalone, Office 2003 Excel standalone and, I think, all editions off  Office 2007. Unfortunately Office 2003 Std is not in this list.

Main VSTO 2005 web site: http://msdn.microsoft.com/office/tool/vsto/2005SE/default.aspx

Useful blogger posts:

Paul Stubbs: Five reasons to love VSTO 2005 Second Edition

John R. Durant: Visual Studio 2005 Tools for Office Second Edition Beta: the Polar Shift

Misha Shneerson: managed addins support in Office 12

Man… Managed code development for the Microsoft Office platform seems like a real dog’s breakfast to me. The problems include:

  • Lack of consideration that developer’s need to develop for the existing customer base. This means a range of Office versions not just the current one.
  • The expense associated with getting a customer to upgrade from one Office version to another. The pricing of upgrades means that the spread of Office versions in the wild is wide. Why should a customer upgrade if (a) the upgrade price is non trivial and (b) the old version does what they need. Let me rephrase that, the old version does what they perceive they need but software developers have to manage supporting a wide variety of versions.
  • Functionality splits that limit the use of Office as a platform. For example, the differences between Office 2003 Standard versus Professional lead to developer’s making choice that move away from using Office as a platform.
  • Crappy COM API legacy. I know this sounds harsh, but it just seems that APIs designed using .NET as a basis seem to just make more sense. Its like having to deal with all the COM plumbing left less resources to think through the structure and usability of the APIs.
  • Deployment complexity.
  • VSTO 2005 document centric nature. This is actually starting to be corrected in VSTO 2005 SE with its addin support, but it was frustrating when VSTO 2005 first came out. A bunch of useful functionality such as task panes and data caching, but not practically usable in my applications because of the document centric structure of the API.

I’m sure that Microsofties could produce valid reasons for why Office .NET development is the way it is and can define how developers should use the available versions of APIs, run times and office versions together. My problem is that its just way too much to learn and for no direct application benefit. Its just a bunch of cruft that gets in the way of application development. Microsoft Office as a platform for software applications has massive potential – even beyond what it is currently. It just seems like the chasm between a useful ubiqitousVBA based development platform and the equivalent modern .NET development platform has yet to be crossed for Microsoft Office.

 

 

Links to this post

Create a Link