Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incompatibility between System.Reactive.Core and System.Reactive.Windows.Threading 3.1.1 NuGet packages #305

Closed
hickford opened this issue Dec 9, 2016 · 15 comments

Comments

@hickford
Copy link

hickford commented Dec 9, 2016

I might be wrong, but I believe there's an incompatibility between the System.Reactive.Core and System.Reactive.Windows.Threading 3.1.1 NuGet packages

  1. https://www.nuget.org/packages/System.Reactive.Core/3.1.1
  2. https://www.nuget.org/packages/System.Reactive.Windows.Threading/3.1.1

Projects in my solution reference both System.Reactive.Core and System.Reactive.Windows.Threading. I extracted the assemblies from the NuGet packages. When I build my solution, it gives a build warning:

warning MSB3276: Found conflicts between different versions of the same dependent assembly. Please set the "AutoGenerateBindingRedirects" property to true in the project file. For more information, see http://go.microsoft.com/fwlink/?LinkId=294190

With diagnostic logging on it gave a bit more information:

 There was a conflict between "System.Reactive.Core, Version=3.0.3000.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263" and "System.Reactive.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263".
     "System.Reactive.Core, Version=3.0.3000.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263" was chosen because it was primary and "System.Reactive.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263" was not.
     References which depend on "System.Reactive.Core, Version=3.0.3000.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263" [C:\bin\System.Reactive.Core.dll].
         C:\bin\System.Reactive.Core.dll
           Project file item includes which caused reference "C:\bin\System.Reactive.Core.dll".
             System.Reactive.Linq
     References which depend on "System.Reactive.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263" [].
         C:\bin\System.Reactive.Windows.Threading.dll
           Project file item includes which caused reference "C:\bin\System.Reactive.Windows.Threading.dll".
             System.Reactive.Windows.Threading

At runtime it gives this error:

Could not load file or assembly 'System.Reactive.Core, Version=3.0.1000.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

@hickford
Copy link
Author

hickford commented Dec 9, 2016

These are the files I extracted from the NuGet packages:

nuget System.Reactive.Core 3.1.1 [lib\net46\System.Reactive.Core.dll|lib\net46\System.Reactive.Core.xml]
nuget System.Reactive.Windows.Threading 3.1.1 [lib\net45\System.Reactive.Windows.Threading.dll|lib\net45\System.Reactive.Windows.Threading.xml]

Inspecting System.Reactive.Windows.Threading.dll in a disassembler, it references

// System.Reactive.Core, Version=3.0.1000.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263
// System.Reactive.Interfaces, Version=3.0.1000.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263

Yet the copy of System.Reactive.Core.dll is a different assembly version

// System.Reactive.Core, Version=3.0.3000.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263

Compare 3.0.1000.0 vs 3.0.3000.0

@hickford
Copy link
Author

hickford commented Dec 9, 2016

Any ideas, what's going on?

@clairernovotny
Copy link
Member

As per #205, this is expected. MSBuild should be generating binding redirects for you though. Do you have AutoGenerateBindingRedirects enabled?

@jairbubbles
Copy link

Hi, I've encountered a similar issue .

Here is a nimimal example where you can see the issue: Issue305.zip (just launch the project)

AutoGenerateBindingRedirects is true in the .csproj so I think binding redirect might not work with nested package dependencies.

The project is targeting .NET framework 4.6. With 4.5 you won't have the issue as version will be 3.0.1000 for all assemblies.
Why not all packages from Rx.net are targetting .NET framework 4.6 ?

@mediabuff
Copy link

Agreed. This is situation is absolutely ridiculous. Please fix the disparate packages nightmare !

@clairernovotny
Copy link
Member

This has been fixed in the v4.0 alpha's on the MyGet feed

@mediabuff
Copy link

Thank you onovotny. Great!

@ghost
Copy link

ghost commented Feb 14, 2018

Hello @onovotny ,
is it possible to release a 3.1.2 nuget (bugfix) package that will fix these issues? In our company we are not allowed to use alpha software (medical software) and these assembly redirects are not created automatically.
We think this a major issue after upgrading from Rx-Main to System.Reactive.

@clairernovotny
Copy link
Member

@DanielMue Rx 4 is still a ways off right now. The binding redirects for 3.1.1 are still the recommended approach as releasing the consolidated library is a major change that may impact some downstream users in a negative way. It's still being sorted out.

Does your project have the <AutoGenerateBindingRedirects> set to true in your project file?

@ghost
Copy link

ghost commented Feb 14, 2018

@onovotny thanks for your fast reply.

We've already tried this workaround without success (test projects and projects with nested package dependencies still require a manually added/edited App.Config):

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Reactive.Interfaces" publicKeyToken="94bc3704cddfc263" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.1000.0" newVersion="3.0.1000.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

It is a runtime exception, the library/application is partially working - that's why we think this is a major issue (our automated test coverage made it visible and prevented a rollout into production).

PS: We are using paket.exe for reproducible builds and dependency management. Could this be a problem?

@clairernovotny
Copy link
Member

Can you try with NuGet. I don't know what Paket is doing and how that might impact generation of binding redirects.

@ghost
Copy link

ghost commented Feb 15, 2018

I tried to convert a small repository to NuGet-only but without success. Your hint using <AutoGenerateBindingRedirects> was very helpful though. After reading the paket documentation again, I found:
https://fsprojects.github.io/Paket/dependencies-file.html#Controlling-assembly-binding-redirects

As far as I understand; setting <AutoGenerateBindingRedirects> to true configures a build step (https://github.com/dotnet/docs/blob/master/docs/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection.md). The *.config file will be modified AFTER a successful build and the assembly binding redirect entries will be added in the resulting Release\bin\*.config file. The original App.config remains unchanged.

Using paket's redirect directive is a different approach. It will modify the original App.config and writes the entries each time you add/remove a nuget package reference. I kinda like this, because it works for all project types (test library, application, ..) and makes these conflicts(?) visible. I guess NuGet has a similar feature (I did not manage to get it working in our repositories though).

@honginstarbucks
Copy link

honginstarbucks commented Apr 30, 2018

is there any real fix without upgrading to the 4.0 prerelease?

I have added the following

      <dependentAssembly>
        <assemblyIdentity name="System.Reactive.Core" publicKeyToken="94bc3704cddfc263" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.3000.0" newVersion="3.0.3000.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Reactive.Linq" publicKeyToken="94bc3704cddfc263" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.3000.0" newVersion="3.0.3000.0" />
      </dependentAssembly>
	    <dependentAssembly>
		    <assemblyIdentity name="System.Reactive.PlatformServices" publicKeyToken="94bc3704cddfc263" culture="neutral" />
		    <bindingRedirect oldVersion="0.0.0.0-3.0.3000.0" newVersion="3.0.3000.0" />
	    </dependentAssembly>
	    <dependentAssembly>
		    <assemblyIdentity name="System.Reactive.Windows.Threading" publicKeyToken="94bc3704cddfc263" culture="neutral" />
		    <bindingRedirect oldVersion="0.0.0.0-3.0.1000.0" newVersion="3.0.1000.0" />
	    </dependentAssembly>
	    <dependentAssembly>
		    <assemblyIdentity name="System.Reactive.Interfaces" publicKeyToken="94bc3704cddfc263" culture="neutral" />
		    <bindingRedirect oldVersion="0.0.0.0-3.0.1000.0" newVersion="3.0.1000.0" />
	    </dependentAssembly>

also turn on to true,

my build still complains

3>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2052,5): warning MSB3277: Found conflicts between different versions of "System.Reactive.Interfaces" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed.
3>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2052,5): warning MSB3277: Found conflicts between different versions of "System.Reactive.Windows.Threading" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed.

it still throws runtime exception.
what can I do? please, thanks!


the only solution I am currently using is: NOT use anything from System.Reactive.Windows.Threading, for example, Dispatcher scheduler.

@EmilAlipiev
Copy link

Hi, I am having this problem after migrating from packages.config to project references? is there any fix please?

@clairernovotny
Copy link
Member

We are close to releasing 4.0. Can you please try the latest version on NuGet?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants