In PR #914 I used the VS SDK ProvideCodeBase attribute to ensure that a particular version of an assembly will load from a specific CodeBase (into the Load context). For example:

[assembly: ProvideCodeBase(AssemblyName = "GitHub.Exports",
    CodeBase = @"$PackageFolder$\GitHub.Exports.dll")]

This can help if another extension references the exact version of an assembly that has been installed (with a ProvideCodeBase attribute). If however a different version is referenced, another assembly will be loaded with a different codebase, static fields and types. Unless our assembly has been designed with side-by-side execution in mind, the results could be unpredictable.

A resolution for this would be to sweep up multiple versions of an using the ProvideBindingRedirection attribute. For example:

[assembly: ProvideBindingRedirection(AssemblyName = "GitHub.Exports",
    CodeBase = @"$PackageFolder$\GitHub.Exports.dll",
    OldVersionLowerBound = "0.0.0.0", OldVersionUpperBound = "2.2.0.9")]

This would prevent old versions of an assembly being loaded at the same time as the current one (they would be redirected to the current one). This would also allowing 3rd party extensions that could work with multiple newer versions of GHfVS (rather than having to be built against a specific version).

This PR depends on #914.
Fixes #926
See #923

There appear to be some bugs when using the ProvideBindingRedirection attribute, which I had to work around. The following doesn't appear to work:

[assembly: ProvideBindingRedirection(AssemblyName = "GitHub.Exports",
    CodeBase = @"$PackageFolder$\GitHub.Exports.dll",
    OldVersionLowerBound = "0.0.0.0", OldVersionUpperBound = "Current")]

(IIRC, this only redirects 0.0.0.0 to the current version 😭)

I had more luck with the following:

[assembly: ProvideBindingRedirection(AssemblyName = "GitHub.Exports",
    CodeBase = @"$PackageFolder$\GitHub.Exports.dll",
    OldVersionLowerBound = "LowestMajor", OldVersionUpperBound = "Current")]

(This redirects all assemblies with the same major version number to the current version)

We could use this for Splat, Rothko, etc. who's assembly versions we don't have constants defined for. For the GitHub.* assemblies, we could take advantage of AssemblyVersionInformation.Version.

I believe the following would work:

[assembly: ProvideBindingRedirection(AssemblyName = "GitHub.Exports",
    CodeBase = @"$PackageFolder$\GitHub.Exports.dll",
    OldVersionLowerBound = "0.0.0.0", OldVersionUpperBound = AssemblyVersionInformation.Version)]

We could use this for Splat, Rothko, etc. who's assembly versions we don't have constants defined for.

Do we need it for those? We will likely never bump versions on our dependencies (except Octokit), so if we need to hardcode things for them, that should be fine.

Do we need it for those? We will likely never bump versions on our dependencies (except Octokit), so if we need to hardcode things for them, that should be fine.

Using the following form (with LowestMajor and Current) works fine if we're only interested in a single major version number:

[assembly: ProvideBindingRedirection(AssemblyName = "Octokit",
    CodeBase = @"$PackageFolder$\Octokit.dll",
    OldVersionLowerBound = "LowestMajor", OldVersionUpperBound = "Current")]

Since we're not likely to bump versions, this certainly applies here. 😄

It just confused me for a while that it isn't possible to use 0.0.0.0 in combination with Current (it failed silently and only bound 0.0.0.0) IIRC! 😕

Here are the current versions we're using:

LibGit2Sharp, Version=0.22.0.0, Culture=neutral, PublicKeyToken=7cbde695407f0333
Rothko, Version=0.0.1.0, Culture=neutral, PublicKeyToken=9f664c41f503810a
Splat, Version=1.6.2.0, Culture=neutral, PublicKeyToken=79cb2fa33d9108a3
Octokit, Version=0.22.0.0, Culture=neutral, PublicKeyToken=5525be5bc50478ea

Can I double-check these are use keys generated by us for GHfVS?

All the submodule projects have their own keys checked in, so you can check those. Libgit2sharp is a nuget package so that's not signed by us. There's also ReactiveUI and Akavache on the list of things we depend on and sign ourselves, I believe?

Libgit2sharp is a nuget package so that's not signed by us.

I've changed it to only provide redirections for GitHub.* assemblies. People shouldn't be using a different version of these inside the same VS instance.

Doing this for Libgit2sharp or any other assembly that might be used by another extension would be a bad thing.

I'm still wondering about Octokit, because it is part of our interface and the version is likely to be bumped in future. It probably should be redirected as well...

I assume we have to wait for #914 to get merged before this one can be merged?

I assume we have to wait for #914 to get merged before this one can be merged?

@shana Yes, and ideally #947 as well. I tried merging this one in as well, but it was proving to be a pain (the combination of a .sln and submodule merge 😕). It obviously can be done, but I'm sure there is less painful way! I've suggested a zoom chat with Jasmine to discuss.

Fixes #926