I ran into a breaking change with Visual Studio 2010 SP1 and VSTO at a client today. It seems there was a change that caused Office addins to look for their config files in the application’s folder instead of from the addin’s folder (e.g. Word.exe.config or Excel.exe.config). The result is all sorts of chaos with AppSettings, WCF service bindings and anything else that needs to be read from the app.config
The bug was caused by a change in the way VSTO 4.0 SP1 reads the Manifest value in the Windows Registry. Previously “[TARGETDIR]MyWordAddIn.vsto|vstolocal“ was valid but the URI has changed in SP1
SP1 expects the Manifest value to have a URI as follows: “file:///[TARGETDIR]ExcelAddIn.vsto|vstolocal”. This has to do with the feature of “Fast Path Loading” which aims to speed up the loading of Office Addins by bypassing a few steps
The most important feature is Fast Path loading, which is a loading path for the runtime which is as fast and as lean as possible. In addition, we updated the form region and ribbon discovery process so reflection is not required in most cases. Plus, I will also share a few of the numbers we gathered during this effort so that you can get a before and after picture. VSTO Fast Path The Fast Path is a new way to load and launch VSTO addins that is much faster than the current launch path. However, it achieves this speed by bypassing a few of the steps that would normally happen during addin launch. The following conditions must be met in order to use the fast path: The addin (or document) manifest must be installed under %ProgramFiles% or %ProgramW6432%. The addin must be registered as |vstolocal in the registry. When the fast path is in use, the following steps will be skipped: Schema validation on the manifests Any automatic update checking Security checks – the digital signatures of the manifests will not be validated.
Interestingly enough Microsoft hasn’t updated their documentation on Deploying Office solutions that target the Visual Studio 2010 Tools for Office runtime.