1

For context, I am making a VSIX for VS2017, and I require System.Text.JSON for serializing/deserializing data.I am using version 6.0.0.0 of System.Text.JSON

If I set CompilerServices.Unsafe to 4.0.4.1 (nuget version 4.5.3) (with appropriate binding redirects (see below)), I get this error:

It wants 6.0.0.0

As you can see, it asks for System.Runtime.CompilerServices.Unsafe version 6.0.0.0. Using ILSpy within the target directory, I can see that the version of System.Runtime.CompilerServices.Unsafe that came bundled was version 4.0.4.1, as expected.

In response, I bump System.Runtime.CompilerServices.Unsafe to 6.0.0.0 (nuget version 6.0.0), I get this error!

It wants 4.0.4.1

That's right - now it wants version 4.0.4.1!

Details

app.config, .csproj, packages.config

...with version 4.0.4.1

When I try with version 4.0.4.1 of CompilerServices.Unsafe, I setup my project like so:

  • I setup app.config with a binding redirect to version 4.0.4.1
<dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.4.1" newVersion="4.0.4.1" />
</dependentAssembly>
  • I add a reference to version 4.0.4.1 on the csproj
<Reference Include="System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
      <HintPath>..\packages\System.Runtime.CompilerServices.Unsafe.4.5.3\lib\net461\System.Runtime.CompilerServices.Unsafe.dll</HintPath>
</Reference>
  • I set it to 4.5.3 in packages.config.
<package id="System.Runtime.CompilerServices.Unsafe" version="4.5.3" targetFramework="net472" />

...with version 6.0.0.0

Similarly, when I set it to 6.0.0.0, I perform the same steps

  • I setup app.config with a binding redirect to version 4.0.4.1
<dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
      </dependentAssembly>
  • I setup the csproj
<Reference Include="System.Runtime.CompilerServices.Unsafe, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
          <HintPath>..\packages\System.Runtime.CompilerServices.Unsafe.6.0.0\lib\net461\System.Runtime.CompilerServices.Unsafe.dll</HintPath>
</Reference>
  • I setup packages.config
<package id="System.Runtime.CompilerServices.Unsafe" version="6.0.0" targetFramework="net472" />

Fix Attempts

A few things I have tried:

  • clear the local package cache (ie, deleting the folder called "packages" at solution root). Result: No Change.

  • remove bin and obj folders. Result: No Change.

  • upgrading system.text.json to version 6.0.7 (Highest version of major version 6.0.0) . Result: No Change.

  • upgrading system.text.json to version 7.0.2 (Latest). Result: No change.

  • downgrading system.text.json. Result: No change.

Owen
  • 65
  • 7
  • 1
    Can't you use SDK-style csproj with `PackageReference` elements for this type of project? Do you really need to manage binding redirects manually like this? – julealgon Apr 10 '23 at 19:02
  • Hello @julealgon, this is just the way that Visual Studio 2017 automatically sets up a VSIX project. Could you please clarify what changes you are suggesting? For my part, I have tried to replace the references to System.Text.Json in the csproj with ProjectReferences (removing any dependencies of the Json library) and got the same failure. – Owen Apr 10 '23 at 19:59
  • 1
    When SDK-style csproj format was introduced, a new, much more streamlined mechanism was added for automatically resolving binding redirects. I'd recommend looking into it as it can be done even for older framework projects without much impact. Once you are using a SDK-style project format, I think the problem would go away without having to fiddle with these values (the entire bindingRedirects section is not needed anymore). Though now that I mention it, there does seem to be [some challenges with it for VSIX projects in particular](https://stackoverflow.com/a/58947835/1946412). – julealgon Apr 10 '23 at 20:44
  • 1
    Also, it looks like they are _just_ finishing official support for it! You might want to keep track of this here: https://developercommunity.visualstudio.com/t/vsix-project-with-sdk-style-csproj/1572145 – julealgon Apr 10 '23 at 20:46
  • 1
    Normal app.config and binding redirect solutions don't work for Visual Studio extensions (vsix), because app.config is only loaded by the .NET Framework runtime for the application (devenv.exe.config), not for dlls. I suggest you look into ProvideBindingRedirectionAttribute and ProvideCodeBaseAttribute. If you use a newer version of VS, I expect these assemblies already ship in VS's "public assemblies" directory, so you probably don't need to ship them in your vsix, but VS2017 is old, so very likely doesn't not have them, so you will have to bundle them in your vsix for that version of VS. – zivkan Apr 11 '23 at 09:16
  • Wow! That worked @zivkan. I will reply back to the main issue. Thank you! – Owen Apr 11 '23 at 13:45

1 Answers1

1

Alright, "I" figured it out (credit to @zivkan for pointing me in the right direction ). Instead of using app.config style of binding redirects (which doesn't work for VSIX) you can instead use ProvideBindingRedirectionAttribute.

I this line to my AssemblyInfo.cs:

[assembly: ProvideBindingRedirection(AssemblyName = "System.Runtime.CompilerServices.Unsafe",
      NewVersion = "6.0.0.0", OldVersionLowerBound = "1.0.0.0",
      OldVersionUpperBound = "4.0.4.2")]

...and, as if by magic, it just works.

See also:

Owen
  • 65
  • 7
  • 1
    Hi Owen, since you found the right way to solve this issue, you can [accept it as the answer](https://meta.stackexchange.com/questions/5234/how-does-accepting-an-answer-work/5235#5235), this will help others when they search for the similar issue in stackoverflow. :) – Bowman Zhu-MSFT Apr 21 '23 at 09:29