Few days back i worked on a problem where a VSTO addin was failing to load after VSTO 4.0 SP1 was installed on the machine. This addin was reading some data from its application configuration file. There was some error during the load of the addin and its load behavior changed to 2 without any error message. During my research, I found that issue is caused by a subtle interaction between the add-in loading enhancements we made in SP1 and app domain configuration behavior in the .NET Framework.

This design requirement was introduced with the new Fast Path add-in loading functionality in the SP1 version of the VSTO Runtime (http://blogs.msdn.com/b/vsto/archive/2010/11/30/performance-improvements-coming-soon-to-a-service-pack-near-you-stephen-peters.aspx). When an add-in is loading via Fast Path and it relies on a *.dll.config file, the manifest path provided for the add-in must be a complete, well-formed URI, including a URI scheme. This new requirement is related to the refined security process for Fast Path loading, and helps ensure that only trusted files are loaded. So for example, if your addin's manifest string value in the registry has following value:

Manifest="C:\Program Files\<Path>\WordAddIn.vsto|vstolocal" 

The addin will fail to load.

To make the addin work, change the value to:

Manifest="file:///C:/Program Files/<Path>/WordAddIn.vsto|vstolocal