Use ProvideBindingRedirection instead of ProvideCodeBase #928
Conversation
|
There appear to be some bugs when using the [assembly: ProvideBindingRedirection(AssemblyName = "GitHub.Exports",
CodeBase = @"$PackageFolder$\GitHub.Exports.dll",
OldVersionLowerBound = "0.0.0.0", OldVersionUpperBound = "Current")](IIRC, this only redirects 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 I believe the following would work: [assembly: ProvideBindingRedirection(AssemblyName = "GitHub.Exports",
CodeBase = @"$PackageFolder$\GitHub.Exports.dll",
OldVersionLowerBound = "0.0.0.0", OldVersionUpperBound = AssemblyVersionInformation.Version)] |
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 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 Here are the current versions we're using: 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? |
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... |
d7dcbe3 to
6b19170
Compare
|
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. |
5368dce to
c88337e
Compare
6b19170 to
9e8d49f
Compare
|
Fixes #926 |
Redirect to the latest `GitHub.*` assembly for assemblies that require a CodeBase (e.g. `GitHub.Exports`). This makes extensions that don't depend on a specific GHfVS version possible.
676e638 to
fef1f8c
Compare
In PR #914 I used the VS SDK
ProvideCodeBaseattribute to ensure that a particular version of an assembly will load from a specific CodeBase (into theLoadcontext). For example:This can help if another extension references the exact version of an assembly that has been installed (with a
ProvideCodeBaseattribute). 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
ProvideBindingRedirectionattribute. For example: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