VSTO Deployment

I’ve been working over the past few months to convert a Visio Add-in I originally developed about 5-6 years ago to migrate it from VB.Net to C# and also to Visual Studio 2008, .Net Framework 3.5, and Visual Studio Tools for Office (VSTO).

The original application design used a small stub of VBA code inside the Visio document to launch the COM Add-in.  This is a somewhat crude approach and it wasn’t a true Visio Add-in, but it has worked well for a number of years.  However, much better capabilities are available now through VSTO to make it very easy to create a true Visio Add-in (or an Add-in for any other Office Application).

Deployment of the completed VSTO Add-in can be difficult – especially on Vista and Windows 7 systems that have tightened up code access security to control what an application is allowed to do (and is not allowed to do).  Here are a few notes on what needs to be done to successfully deploy a VSTO Add-in:

1. How the application stores and accesses files on the target system needs to be carefully thought out.  In the past, many applications simply put all files (both application files and data files) in the C:\Program Files location.  This approach no longer works on Vista systems because Vista will not allow an application to write or modify files in that area at runtime unless it is running with Administrator privileges.  My recommended strategy is this:
   • Use the Program Files directory only for application files that are only written or modified when the application is installed.
   • Create a folder in the user’s “My Documents” area for any documents that the user might create or modify while he/she is using the application.
   • Create a folder in the LocalApplicationData area for any other files that are written or modified by the application at run-time that do not need to be easily accessible to the user (for example configuration files and application data files).  On Vista systems this folder is located at C:\Users\<UserName>\AppData\Local
2. The Office Add-in must be granted full trust in order for the VSTO loader to load it at run-time.  Problems with the VSTO loader not loading an application can be elusive to track down because the VSTO loader doesn’t seem to report all errors (even if you have error logging turned on).  Sometimes it just refuses to load the Add-in and doesn’t provide an error message or any indication that the Add-in hasn’t been loaded.  In order to grant full trust to your Add-in, you must include an installer project that creates a code access security policy to grant full-trust to the application.   I recommend going beyond that and assigning full-trust to the entire installation directory, especially if you have other DLL’s in the installation directory that also must be trusted for the application to run.  Here are some references for more details on how to implement this:
• SetSecurity Project Code and Instructions
• Modifications to Grant Full Trust to the Install Directory
• My MSDN Forum Topic on this Subject
3. Make sure that all the required prerequisites are included in the installer package. The obvious ones are:
   • .Net Framework 3.5 (or whatever other version you used)
   • VSTO Runtime
   One that is not so obvious is the ".Net 3.5 Framework Client Profile". The "Framework Client Profile" is supposed to be a subset of the full .Net Framework, so it seems redundant to include it and and the full .Net Framework, but it does seem to be necessary.

Chuck