Deploying Departmental Solutions via Email (Christin Boyd)

A lot of VBA developers tell me that they love VBA solutions because there is no deployment necessary.  All the code lives inside the document itself, so all you need to do is get the document (in e-mail or on SharePoint) and you have everything you need to get the job done.  Then there are some really cool things you can only do with VSTO that you can’t do with VBA, such as programming with LINQ, building Action Panes, using WPF controls, and the overall fun of .NET programming.  So I’m frequently asked how to get a similar e-mail or SharePoint scenario with a VSTO solution.

Here is one way of accomplishing the e-mail deployment scenario.  You develop an Word document solution (or an Excel, or a template solution).  You publish it to a server where users can copy the document for use.  Jody from human resources copies the document to his local machine and makes some edits to the document, adds some text, and uses VSTO features such as an Actions Pane to retrieve information from PeopleSoft or some other line of business system.  Then Jody sends the document to Abby using an e-mail attachment.  Abby saves the document to her local drive, opens the document and adds information about her department to the document using both features of Word and features from the VSTO solution.  At no point does Jody or Abby run a setup.exe.  They just send the document around like they always did.  This blog post will try to explain how you can accomplish this scenario.  Some pre-requisites to this scenario are: 

  • The first time the users (Abby and Jody) try to open the file, they must have network access to the same server URL or web URL, such as a departmental server or intranet site.  After the first use, the users can be offline because the assembly will be loaded in the ClickOnce Cache.
  • The users (Abby and Jody) have the .NET Framework 3.5, the VSTO Runtime, and Microsoft Office primary interop assemblies installed on their computers already.  This can be accomplished company-wide using SMS or any other software management system. For more info, see the blog entry Deploying Prerequisites for Your Visual Studio Tools for Office Solution.
  • This scenario only works with Office 2007 solutions.  VSTO does not use the ClickOnce Cache when deploying Office 2003 solutions.

You can use Visual Studio 2008 to Publish your solution to a server or web site.  You should choose a web site where all of the people in your workgroup have access.  Let’s use the fictitious server location \\HRServer\apps\.  In Visual Studio 2008, on the Project menu click <ProjectName> Properties, and then click the Publish tab.  Enter the server path or web site in both the Publish location and Install location as seen here:


What do these settings mean?  The first path determines where Visual Studio will try to copy all of the deployment files when you click the Publish Now button.  The person who pushes the Publish Now button needs to have permissions to write to the target directory.  The second path, Installation Folder URL, determines the string that gets written to the MySolution.vsto file.  Try this yourself and then look at the *.vsto file in Notepad or an XML editor to see where your URL gets stored.  Make sure not to permanently associate the .vsto file extension with Notepad.exe.

To test your deployment, it is better to not use your development computer.  Your computer likely has a version of the solution already deployed from when you ran the solution in the Visual Studio debugger.  I strongly recommend that you use another computer, or a Virtual PC image to test your deployment. 

You will need to install Microsoft Office, the Office primary interop assemblies, the .NET Framework 3.5 and the VSTO 3.0 Runtime on the test computer.  Now you can send e-mail or copy your document from the server (in this example \\HRServer\apps\mydoc.docx) to your local computer.  If you try to open the document directly from Outlook, then you will get an error because Outlook’s temporary files location is not a trusted location.  Because it is not a trusted location, the Runtime won’t try to load the assembly and the user won’t even get a prompt to install the assembly.  Instead, the user should Save the document to a trusted location, such as in My Documents.  When the document is opened from a trusted location such as on your own hard drive or from a trusted server, then everything should work. 

When you open the document, the VSTO runtime will look inside your docx file and find the path to the server.  If you are using the Open XML file format, then you can see exactly where this information is written by renaming your file to *.zip, then opening it to see all the folders hidden inside.  You should see a folder called vstoDataStore, and another folder called docProps, and a few others.  The interesting stuff is inside docProps\custom.xml you’ll find the string that shows the full path to your assembly on the server.  The interesting node inside of custom.xml will look something like this:

<property fmtid=”{D5CDD505-2E9C-101B-9397-08002B2CF9AE}” pid=”2” name=”_AssemblyLocation“>



Next you can remove the test computer from the network and try to open the document again.  The solution continues to work because the assembly has been installed on the user’s computer!  You can look in Control Panel in Add/Remove Programs to see your assembly listed.  You have now successfully deployed a solution via e-mail!  Does this feel insecure?  Well, if you did not use a Certificate to sign your solution, then every user will get prompted with a warning that the assembly is from an Unknown Publisher.  That will scare them!  We recommend that you get Certificates from your IT department or from an independent Certificate Authority. 

If you are unable to use a real certificate, we recommend against creating a temporary certificate.  Instead you can create an inclusion list entry to automatically grant trust to your VSTO solution by saving the certification information and the network location of the assembly’s deployment manifest. For more information, see Trusting Office Solutions by Using Inclusion Lists (2007 System).

The information in this blog entry is meant to complement the existing documentation for Visual Studio 2008.  Please leave a comment to let us know if this blog entry is useful or let us know if there is an error in the text.  Thank you!

-Christin Boyd, Program Manager