Upgraded your VSTO 2010 Runtime? The Manifest Registry needs an upgrade too!
A few months ago (okay, SEVERAL months ago), around the time of March, we started pushing out an updated version of VSTO 2010 Runtime that bumped up its version from 10.0.30319 to 10.0.31007. This happened either through an update of your .NET Framework or if you downloaded the VSTO Runtime from the Download Centre link on or after 15th April 2011. After the release of Office 2010 SP1, this version stands at 10.0.31117.
This update wasn't completely unannounced, as the VSTO team had announced its coming many months before (https://blogs.msdn.com/b/vsto/archive/2010/11/30/performance-improvements-coming-soon-to-a-service-pack-near-you-stephen-peters.aspx?wa=wsignin1.0)
One significant feature of this update (or atleast what has come to be significant since) is the introduction of Fast-Path Loading.
You can either go back to the previously-mentioned blog and read-up about what exactly is Fast-Path loading, or I can save you the trouble and reproduce it here:
Original Source: https://blogs.msdn.com/b/vsto/archive/2010/11/30/performance-improvements-coming-soon-to-a-service-pack-near-you-stephen-peters.aspx?wa=wsignin1.0
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.
Notice that the requirement that the add-in is deployed into the secure location on the user machine allows us to relax the security verifications done at runtime without compromising the security of the machine. Relaxing these expensive checks is what contributed the most to the improvements in startup time.
In order to take advantage of Fast Path loading, an addin has to be deployed via an MSI. As a consequence, these addins also will not be able to automatically check for updates.
What this announcement did NOT mention (for it was to be discovered later) is that you would have to make a *small* tweak in your Manifest Registry key for add-ins running on this and subsequent versions of the Runtime, to avoid a plethora of issues.
One of these plethora of issues were documented by Ajay Bandooni earlier in June, and more of them came up in the recent weeks. I thought I would put out this update to y'all before I get any more emails from *concerned* developers confronting issues pertaining to this wrongly-misinterpreted-as-bug enhancement of the runtime :-)
1. Your add-in, that attempts to read a *.dll.config file will not be able to read the content of that config file, even though the add-in appears to load/work normally otherwise
2. Your add-in, that attempts to read the *.dll.config file and is reliant on it for loading, will fail to load and LoadBehavior will fall from 3 to 2.
3. Your add-in does not have any *.dll.config file associated with it, and loads normally on Windows Vista and Windows 7, but is unable to accomplish the same feat in Windows XP
4. You try to programmatically access the path of the ApplicationDirectory, and access files located there. Eg: Retrieving path via System.AppDomain.CurrentDomain.SetupInformation.ApplicationBase or System.AppDomain.CurrentDomain.SetupInformation.PrivateBinPath
5. Other unforseen (as yet) circumstances ... <Will be updated upon discovery>
So what exactly is that **small** tweak?
Well, your Manifest Registry Key, that used to be a simple, straightforward file path such as C:\Program Files\ThisIsMyAddIn\ThisIsMyAddin.vsto|vstolocal would now be a well-formed URI with a URI-scheme.
In other words, if your Manifest Registry key earlier read "C:\Program Files\ThisIsMyAddIn\ThisIsMyAddin.vsto|vstolocal"
It would now be a slightly more puzzling, but definitely more scientific "file:///C:/Program Files/ThisIsMyAddIn/ThisIsMyAddin.vsto|vstolocal"
Now that wasn't so hard, was it now!
Again, we're discovering other scenarios in which the issue shows its fangs, almost every other month. So if your add-in magically starts throwing issues after updating the VSTO 2010 Runtime (to version 10.0.30017 or higher), give this modification a shot, and see if it fixes the issue. If it does, do please drop in a comment mentioning your scenario, in case it can help another comrade, and I'll be sure to update it into this post.
A warm "Thank You" to all the customers who reported these scenarios to us, for the information and for their patience!
Cheerio!
Comments
Anonymous
September 05, 2011
I have this strange issue, maybe you can help me out. The system is window 7 with office 2010 I have a word add-in which install correct and the registry key shows file:///c:/.... then I have an other word add-in which doesn't install because the registry key shows c:..... If I manually change this to file:///c:/... this add-in also installs correctly. The code in the setup project for setting the registry key in both projects uses [targetdir]addinname.vsto Do you have any idea why the one is showing file:///c:/... and the other is showing c:... ? Or can you give me an example of how to set this registry key to file:///c;/.... instead of c:..... Thanks in advanceAnonymous
September 09, 2011
Hey Marco, That's quite easy really... Just alter the "Manifest" registry key in your add-in project from "[TARGETDIR]AddInName.vsto|vstolocal" to "file:///[TARGETDIR]AddInName.vsto|vstolocal" You'll find that the resultant reg key created looks like "file:///C:Program Files...AddInName.vsto|vstolocal" but that should work just fine... DhruvAnonymous
October 09, 2011
Sorry the late response. That is quite easy indeed :-) Thanks a lot for your answer and blog post. Marco