Sdk: Desktop binding redirects can be generated incorrectly when built multiple times - Explosions at runtime

[NTaylorMullen]

Steps to reproduce

• Create project:

{
  "version": "1.0.0-*",

  "buildOptions": {
    "emitEntryPoint": true
  },

  "dependencies": {
    "dotnet-test-xunit": "1.0.0-rc2-*", /* This references Newtonsoft.Json 7 */
    "xunit": "2.2.0-*"
  },
  "testRunner": "xunit",
  "frameworks": {
    "net451": {}
  }
}

``` C#
namespace TestTestProject
{
public class Program
{
public static void Main()
{

    }
}

}

- `dotnet restore` original project
- `dotnet build` original project, binding redirect has Newtonsoft entries:

``` XML
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="6.0.0.0" newVersion="7.0.0.0" />
      </dependentAssembly>

• Create a second project SomeDependencyProject

{
  "version": "1.0.0-*",

  "dependencies": {
    "Newtonsoft.Json": "9.0.1-beta1"
  },

  "frameworks": {
    "net451": {}
  }
}

``` C#
namespace SomeDependencyProject
{
public class Class
{
}
}

- `dotnet restore` the dep project
- `dotnet build` the dep project
- Reference `SomeDependencyProject` in your original project.
- `dotnet restore` original project
- `dotnet build` original project, binding redirect now looks like:

``` XML
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="6.0.0.0" newVersion="7.0.0.0" />
        <bindingRedirect oldVersion="7.0.0.0" newVersion="9.0.0.0" />
        <bindingRedirect oldVersion="6.0.0.0" newVersion="9.0.0.0" />
      </dependentAssembly>

This is an incorrect binding redirect.

• dotnet test at command line: Explosions trying to load Newtonsoft.Json 7.0.0.0 since it's the first entry in the list (shouldn't even be there).

Expected behavior

• Correct binding redirect, and running works.

  Actual behavior

• Explosionss, could not load Newtonsoft.Json 7

  Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview2-002966)

Product Information:
 Version:            1.0.0-preview2-002966
 Commit SHA-1 hash:  b512ddb8b8

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10586
 OS Platform: Windows
 RID:         win10-x64

/cc @javiercn @Eilon @pranavkm @muratg

This is blocking consuming the new xunit package and the new Newtonsoft.Json package together.

[muratg]

cc @Petermarcu @piotrpMSFT

[JunTaoLuo]

I'm not sure what has changed but with either a new CLI or a new dotnet-test-xunit package, I no longer see the problem.

I am still able to reproduce this issue using older CLI 1.0.0-preview2-002966 and rc2 dotnet-test-xunit 1.0.0-rc2-build10025 where I see the following redirects:

      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="6.0.0.0" newVersion="7.0.0.0" />
        <bindingRedirect oldVersion="7.0.0.0" newVersion="9.0.0.0" />
        <bindingRedirect oldVersion="6.0.0.0" newVersion="9.0.0.0" />
      </dependentAssembly>

If I use the RTM CLI 1.0.0-preview2-003118 or a newer dotnet-test-xunit 1.0.0-rc2-192208-24, or both, the correct binding redirects are generated:

      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="7.0.0.0" newVersion="9.0.0.0" />
        <bindingRedirect oldVersion="6.0.0.0" newVersion="9.0.0.0" />
      </dependentAssembly>

It would be nice to figure out what changed here and why the new CLI or dotnet-test-xunit package rectifies the issue.

[JunTaoLuo]

I misspoke on the previous comment 1.0.0-rc2-build10025 is the newer version of dotnet-test-xunit which will be released for RTM. 1.0.0-rc2-192208-24 is the old version. The results are still the same.

[TheRealPiotrP]

dupe of dotnet/cli#4514, for tracking purposes. dotnet/cli#4514 will use the SDK's binding redirects generator, avoiding this issue altogether.