Introduction

It may seem backwards to first start out with a technical introduction to a case and in the next post, as in this one, discuss what VSTO is and what is not from a broad perspective. In a way it reflects how life is or how it can be when we plan our work but cannot work our plan.

In the early 2000’s Microsoft released their new platform for software development, .NET, and as this is writing the present version is 2005 (previously versions are 2002 and 2003) and the beta of the next coming versions, 2008, has recently been released.

Today it’s common that the major software vendors release new versions and shortly after they announce that the next versions of the development tools are in their first beta stage. This is one of the new paradigms we face and although it may look attractive it’s not doable to keep the same speed as the vendors do (and want us to do). As a general thumb rule the following should be applied (it’s easy to write but it’s harder to follow especially in my case):

Be one step ahead of the general business evolution but not two steps ahead as we otherwise will lose the focus on business needs.

However, the .NET platform has reached the stage of maturity and it’s both reliable and stable. As with all kind of new technology it would be easy to write a book about what .NET is however in this context it may be satisfying to say that .NET is a huge group of classes with a strong focus on security. It offer us the possibilities to create Windows applications (i.e. desktop applications), Database applications and Web applications. .NET is rapidly moving to the position of being the de facto standard for general software development. For the average OBAD (Office Business Application Developer) .NET should be viewed as a platform to learn and adapt in order to stay in business in the long run. Sure, there is no immediate need to do so but since it can be a quite challenging process to learn .NET the sooner you start out the process the better.

When it comes to developing Office solutions with Visual Studio.NET they can be categorized in one of the following two groups:

• Automation of one or several Office Application(s); or
• COM Add-ins that target one or several Office Application(s).

We can therefore conclude that Visual Studio.NET is the successor of Visual Studio 6.0 and earlier versions of it. In my case I still have the Visual Studio 6.0 in the “toolbox” and to which I have added Visual Studio.NET. After all, I still need to maintain customized solutions and in some cases customers explicitly state to avoid .NET for new solutions.

Visual Studio Tools for Office (VSTO)

Microsoft wanted to support development of OBAs (Office Business Applications) on the .NET platform and the birth of VSTO did not come as a surprise. However, VSTO has had a regretful bad start:

• The rush to release version 1.0 caused a lot of badwill due to the great number of bugs and shortcomings including issues with deploying solutions.
• The difficulties to explain what VSTO is and what we can do with it. This has also caused some confusion as well as frustration among developers, especially among the group that bought VSTO just to find out that it wasn’t the tool they assumed it is.
• At present it exists in two versions; VSTO 2005 and VSTO 2005 Second Edition (SE), which makes it more difficult to understand what VSTO is and what we can do with it.

The next version, at present available in the beta version of Visual Studio 2008, will be one version only (with strong simplified solutions for deployment and security).

What we need to understand is that the really difficult challenge for the VSTO team is to find solutions/workarounds enabling a 100 % .NET based tools (as VSTO) to communicate with COM Applications in the Office suite and vice versa.

What VBA is not

• VBA is not part of VSTO and will never be (some people believe that VBA “qualifies” for being part of Visual Studio Tools as it’s per se a tool with which to create OBAs.)

What VSTO is not

• VSTO is not the successor of VBA (and it has never been that).
• The new tool to separate data from business logic for OBAs. We have done it for the last 15 years or so and it’s already a de facto standard.
• A tool to developing UDFs despite the possibility to do so. It’s complex, tricky and produces solutions with slow performance and speed.

VSTO is a .NET based toolkit

• To develop Document level solutions, i.e. individual Excel workbooks and templates, where the “code-behind” can be detached as well as attached again in an easy manner.
• To develop Application level solutions, i.e. add-ins.
• That enables us to work with data between databases and Office applications in many new great ways.

Since VSTO is a .NET based tool we can use and leverage ADO.NET in all kind of VSTO solutions. VSTO also provides us with new Office objects, for instance in Excel the “NamedRange” and ListObjects are new objects, which improves and provide us new ways of data binding.VSTO comes with an additional new feature to store data in datasets embedded in documents. In that way we can work “locally” with the cached data and later load the updated data up to the central database.

All in all, in my opinion these are the best features of VSTO.

• It makes it possible to use Windows Forms and use all the related controls to Windows Forms in OBAs.
• Applying .NET security in VSTO solutions requires that we set up Code Access Security (CAS) schemas so that the operating system and the targeting Office applications knows (via the .NET Framework) how to handle the solutions.
• It put demands on the developers to have good knowledge and understanding of:
• .NET Framework especially the security aspect
• How to work with ADO.NET
• How to work with VB.NET or with C# and
• How to work with the Office Object model(s) through the Interop and VSTO layers.

Requirements

It’s not easy to get an understanding of what is required to:

1. Develop VSTO solutions; and
2. To use VSTO solutions.

I have compiled a list of requirements which is available here. For additional information please see:

• Can You build one add-in for multiple versions of Office?
• Why is VS development not supported with multiple versions of Office?

From what I understand the new version of VSTO will only be supporting Office 2007 and later versions. It means that today issues with the present VSTO versions and Office 2003 will exist forever or at least until everyone has moved to Office 2007 and later.

When to use VSTO and who should use it?

In my opinion VSTO can be used when the following criteria are met:

• A 100 % controlled environment where demand for .NET based solutions already exists and where the environment’s security policy can continued be fully supported.
• A 100 % unified environment when it comes to Windows version in use as well as Office version in use (Office 2003 Professional or Office 2007 and later).
• One entry point within the environment for testing and rolling out VSTO solutions.

Small and independence OBADs tend to work with small and medium sized companies with a mix of Windows and Office versions in use. In this case it simply would not be doable to implement VSTO solutions.

When it comes to OBAs , there seems to be a time lag between the latest technologies and the general business requirements (at least from a historical perspective). In other words there are some good “excuses” to wait and see when it comes to new technologies like VSTO.

From my point of view “tomorrow is always around the corner” and what we invest today may turn out to be a good investment when “tomorrow” is here. After all, VSTO is a new tool to be added to our never ending growing “toolbox” which we develop customer’s solutions with.

Conclusions

While Visual Studio .NET has reached its maturity stage VSTO is only in its early stage. As with every new tool it will take some time before it reach the maturity stage.

What we know is that the .NET platform is here to stay which is also true when it comes to VSTO. No matter when we decide to “jump” on the “ .NET wagon” it will be a difficult process of learning .NET. Compared with other group of developers we, OBADs, don’t need to learn the Office Object model which is a great advantage.

I can fully understand that the price model Microsoft applies for development tools like VSTO is the major “stop” for us all. The high pace of releasing new versions is not economically feasible for the large group of OBADs.

In my opinion we would all benefit (including Microsoft) if Microsoft would make new development tools available in a similar way as the Office and Windows are made today through the “Microsoft Action Package”.

Last words

When I approached VSTO the very first time I constantly compared it with “good ol’” VBA. Over the time I have come to the insight (right or wrong) that VSTO should be reviewed on its own. After all, there exist no other tools on the .NET platform to develop OBAs with.

I hope that this blogpost shed some lights on what VSTO is and what we can do with it. In the next blogpost I will continue to discuss the case for creating and deploying managed COM add-ins.

Finally, VSTO is not two steps ahead the business progress and needs only one step.

Kind regards,

Dennis