Battling the Visual Studio Tools for Office Demons!
For the last few months I have been battling VSTO demons which would cause an Outlook 2007 addin to work perfectly fine on everyone else's machine but mine! Arrgh! My first suspicion was on the Code Access Security (CAS) policies but on comparing those on my machine with others those seemed perfectly correct – my addin binaries were running with FullTrust. Off course the other problem that makes this hard is I get no error message – just the status on the addins dialog that says "Addin failed to load due to a runtime error". I eventually ran into this article and the VSTO_SUPPRESSDISPLAYALERTS environment variable and suddenly things got sorted real quick. So here's what happened and hopefully this will save someone else a ton of head scratching and heartache!
- Open a command window and issue set VSTO_SUPPRESSDISPLAYALERTS=0
- Run outlook.exe from the same window
- Outlook launches and when I try to load the addin I get an exception message (finally!) that looks like this:
An add-in could not be found or could not be loaded.
-----------Details----------------
Could not load type 'Microsoft.Office.Tools.AddIn' from assembly 'Microsoft.Office.Tools.Common, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
************** Exception Text **************
System.TypeLoadException: Could not load type 'Microsoft.Office.Tools.AddIn' from assembly 'Microsoft.Office.Tools.Common, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
at System.Reflection.Assembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase)
at Microsoft.VisualStudio.Tools.Applications.Runtime.AppDomainManagerInternal.CreateStartupObject(EntryPoint entryPoint, Dependency dependency, Assembly objectAssembly)
at Microsoft.VisualStudio.Tools.Applications.Runtime.AppDomainManagerInternal.ConfigureAppDomain()
at Microsoft.VisualStudio.Tools.Applications.Runtime.AppDomainManagerInternal.LoadAssembliesAndConfigureAppDomain(IHostServiceProvider serviceProvider)
at Microsoft.VisualStudio.Tools.Applications.Runtime.AppDomainManagerInternal.ExecuteCustomization(IHostServiceProvider serviceProvider)
|
- Load up the appropriate binaries in ildasm / Reflector and I can immediately see the problem. I have a dependency issue – the VSTO runtime I have on my machine is not what the addin was expecting. Now the installer was meant to have dealt with this though its setup.exe bootstrapping process but I guess not.
- So off to Microsoft Downloads to download the latest version of the runtime; install the runtime and launch Outlook and boom everything now works! J
So what happened here. Well I was the original developer of this addin about a year or so ago and was developing it using Visual Studio Tools for Office 2005. As a consequence of this I already had that runtime on my machine. Another developer since took that over and moved up to using Visual Studio Tools for Office 2005 SE. On my machine I already had the original runtime installed and as it so happens the bootstrapper could not detect that I needed to be upgraded to the latest and greatest SE runtime. Instead it assumed I already had the runtime and simply went about installing the actual addin. And that's how and why I ended up above.
Anyways I think the most helpful was the environment variable above without which I would be still stuck. Sounds like debugging VSTO solutions could be made a lot easier at runtime.