Ensure GitHub.TeamFoundation.15 MEF assembly is always installed on Visual Studio 2017

[jcansdale]

What's the issue

Specifying a TargetVersion was causing the GitHub.TeamFoundation.15 MEF assembly to sometimes incorrectly be excluded when installed on Visual Studio 2017 (see #1859).

@dgriffen said:

the bug is that sometimes servicehub's version is used which is not tied directly to the VS version (currently, its ~1.3 I think).

What this PR does

Assuming this issue is fixed in 2019, we can assume that when the version is reported as 1.x (instead of 15.x) we're installing for Visual Studio 2017. Specifying a version range isn't supported when installing for Visual Studio 2015, so this isn't an issue there.

• Install for Visual Studio 2017 when version is incorrectly reported as 1.x

How to repro

1. Install GitHub for Visual Studio v2.5.4.3349 in Visual Studio 2017
2. Launch Visual Studio 2017 (with the GitHub and Team Explorer panes closed)
3. Open the folder at: %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\15.0_xxxxxxxx
   (where 15.0_xxxxxxxx is a unique name corresponding to the instance of Visual Studio you're running)
4. Delete the folder ComponentModelCache
5. Delete the file Extensions\extensions.en-US.cache
6. Kill the process ServiceHub.VSDetouredHost.exe
   
7. Open any solution that has a Git repository (you might see the dialog below at this point)
8. Close and re-open Visual Studio 2017
9. Open any solution that has a Git repository
10. Expect to see the following dialog:
    
11. If you've ever accidentally selected no on the above dialog, you won't see anything. 😢 Try running the View > Other Windows > GitHub. Expect nothing to happen.

The extensions cache (extensions.en-US.cache) is now corrupted. 🎉 😭 The only way to fix it is to delete Extensions\extensions.en-US.cache and ComponentModelCache and relaunch Visual Studio.

How to test

Following on from How to repro...

1. Install the version from this PR
2. The extension should now be working
3. Repeat from step 2. of How to repro
4. Expect the extension to continue working this time

Phew! 🤞

Related

Fixes #1859 Corrupt extension cache and missing MEF exports
Fixes #1826 GitHub Extension broken with VS 15.7.6
Fixes #1810 SetSite failed for the package [GitHubPackage], VS 15.8 Preview 4/5
Fixes #1812 Error On Project Load

[grokys]

Are we sure it's always servicehub's version that's being used, or is it just a random assembly that's loaded into the process? If the latter, then this won't fix the problem I guess...

Might it be best to just remove the version check and fall back to MEF erroring out as before? This is what we're doing for 2015 after all, right?

[jcansdale]

I'm guessing the issue is that the version of vs_installerservice.exe is being used (which is 1.3.x) rather than VSIXInstaller.exe (which is 15.7.x).

I'd like to find out when servicehub's version is being used so we can test the proposed fix. Hopefully @dgriffen will be able to point us in the right direction.

[ZoeyR]

The version is actually the version of the VSDetouredHost which can be found in Common7\ServiceHub\Hosts\ServiceHub.Host.CLR.x86\ The reason this happens is that the VSDetouredHost loads a copy of the extension manager which may try to write to the extensions cache.

This fix should work but you'll want to test it to make sure you don't see the issue popping up still. I don't know enough about why you started using the target versions to say if this approach is better than just falling back to always attempting to load it.

[jcansdale]

@dgriffen,

I don't know enough about why you started using the target versions to say if this approach is better than just falling back to always attempting to load it.

The problem was that the MEF log ended up looking this this when the extension installed normally. This made diagnosing MEF issues for our own and other extensions problematic (you needed to know which exceptions to ignore in order to find any genuine issues).

The reason this happens is that the VSDetouredHost loads a copy of the extension manager which may try to write to the extensions cache.

When should I expect ServiceHub.VSDetouredHost.exe to run? I'm hoping I can simply delete the component cache and then do whatever causes it to run?

[ZoeyR]

When should I expect ServiceHub.VSDetouredHost.exe to run?

The timing is tricky and I was never able to reliably produce a cache that wouldn't get detected as invalid by the next launch of VS. VSDetouredHost runs whenever someone requests a servicehub service that is not installed in the Common7\ServiceHub\Services. The most common time for this is project load. After you get it to regenerate the cache you will need to shutdown VS and delete the ComponentModelCache folder to trigger it to regenerate from the broken state.

[jcansdale]

@dgriffen, thanks. I've added How to repro and How to test sections to the PR. I'm able to trigger it relatively consistently, even it this isn't exactly what is happening in the wild.

[grokys]

It's a hack, but it seems to fix the problem until VS gets a bugfix. 👍

[jcansdale]

From @meaghanlewis

i was finally able to repro consistently and was just finishing testing out the build from the PR
yeah it LGTM 👍

Merging...