Expected BindingRedirect behaviour with System.ValueTuple on net47x

[simonlampen]

I had been having issues with System.ValueTuple but upgraded to the latest release 4.6.2.

I have read through other related issues eg #243

Now I have binding redirect issues and just wanted to check: when a package is redirected to the "inbox" version, should auto generating the redirects be aware of this, as at the moment, auto generated redirects break dll resolution for System.ValueTuple.

Here is our situation:

• System.ValueTuple was a nuget Package that some other Packages still (transiently) reference today
• System.ValueTuple is part of the .NET Framework from net47x, so should load the "inbox" fx version
• Transient references still appear to require binding redirects (eg if we don't have a redirect we still get errors like "Error during LoadMefPartsFromDirectory while loading from dir: Could not load file or assembly 'System.ValueTuple, Version=4.0.5.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified."
• Having a redirect like the following does fix these loading issues:

      <dependentAssembly>
        <assemblyIdentity name="System.ValueTuple" culture="neutral" publicKeyToken="cc7b13ffcd2ddd51" />
        <!-- pin to the net472 internal framework version ie 4.0.0 for older package references -->
        <bindingRedirect oldVersion="0.0.0.0-4.0.5.0" newVersion="4.0.0.0" />
      </dependentAssembly>

• either: AutoGenerateBindingRedirects and GeneratedBindingRedirectsAction do not appear to understand that they should generate redirects to the framework version, and instead generate redirects to the nuget package version, which causes runtime errors, they generate redirects like this:

      <dependentAssembly>
        <assemblyIdentity name="System.ValueTuple" culture="neutral" publicKeyToken="cc7b13ffcd2ddd51" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.5.0" newVersion="4.0.5.0" />
      </dependentAssembly>

• or the framework does not appear to understand it should ignore the redirect version.

As far as I can see, the only option is to switch off AutoGenerateBindingRedirects, or implement some post generation hook to put it back to the inbox version.
Is this something the package has control of, or is it all framework?
Am I missing some other config to get this to work smoothly

[ViktorHofer]

@ericstj

[ericstj]

@simonlampen make sure you're using the latest package. When using the latest package in the application (the one that would normally generate bindingRedirects) those bindingRedirects should no longer be generated. Be sure to remove any bindingRedirects that might exist in your source code -- #258 discusses what can happen if those aren't removed.

If you still face an issue when doing this you will need to either provide a repro project or a binlog and fusion logs showing the runtime error.

I noticed your error message has "LoadMefPartsFromDirectory" -- I'm not familiar with this method name-- I wonder if you have a custom loader involved that's somehow not applying framework policy and this is just the first time you have an assembly name that requires framework unification. The fusion log might reveal this.