Hi -
I'm the developer of a VS extension that performs automated testing (www.ncrunch.net). Since the VS2012 release, I've had some users reporting issues related to the extension not being loaded by Visual Studio after its installation. The occurrence of these problems seems to be fairly rare (less than 1% by my guess), but when it happens, it's serious, as there doesn't seem to be a way of fixing the Visual Studio state so that it will ever load the extension again.
The issue affects VS2012 and VS2013. To my knowledge, VS2010 is not affected. VS2008 I am not sure of.
The MSI installer copies the extension package files underneath the C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions directory, then runs 'devenv.exe /setup' to instruct VS to refresh its extension cache and load the package. 99% of the time, this works fine, and it has always worked fine in my own development environment and in every test environment I can access.
However, in some rare cases, VS will seem to 'think' that it's loaded the extension, but it actually does nothing with it. It doesn't call into the package code, or load the VSCTs, or anything else that allows the package to fire up and work.
The VS log shows the following and nothing else of relevance:
<entry><record>340</record>
<time>2013/10/23 22:47:31.092</time>
<type>Information</type>
<source>Microsoft.VisualStudio.CommonIDE.ExtensibilityHosting.VsShellComponentModelHost</source>
<description>Successfully loaded component assembly from cache</description>
<path>C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 12.0\COMMON7\IDE\EXTENSIONS\REMCO SOFTWARE\NCRUNCH FOR VISUAL STUDIO 2013\nCrunch.VSIntegration2013.dll</path>
</entry>
Running 'devenv.exe /setup' again does not resolve the problem. Neither does removing all the extension files and running 'devenv.exe /setup', then reinstalling. Clearing out the .cache files underneath C:\Users\[USER]\AppData\Local\Microsoft\VisualStudio\12.0\Extensions makes no difference. Nor reboots or any combination of the above.
The only thing that seems to make a difference is if VS is loaded using a different registry hive, for example:
'devenv.exe /rootsuffix other'
This allows the extension to immediately load without problems inside the alternative registry hive. Of course, this results in loss of settings and it isn't really a good way to keep people working as the normal registry hive still seems to be hosed.
I have had a user manage to resolve this problem by uninstalling all of Visual Studio, then manually removing any files remaining, and manually searching and removing all VS references from the registry. This isn't a solution I'd like to recommend to people as it's very time consuming/expense for them.
As much as I'd love to see this problem resolved in VS, I have to be realistic in saying that I have no idea how to reproduce it myself and provide only very limited data on the environments in which it occurs.
Instead, I'd really like to know more about where Visual Studio stores/caches data on its extensions and how this data can be completely cleared. It must be possible to clear the corrupt extension state in a way that allows the package to load normally, without needing to rip VS out of the whole the system. As the /rootsuffix parameter seems to make a difference, I would guess this to be in the registry somewhere? Can anyone help?
Thanks!
Remco