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
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)
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
Any ideas, what's going on?
As per #205, this is expected. MSBuild should be generating binding redirects for you though. Do you have AutoGenerateBindingRedirects enabled?
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 ?
Agreed. This is situation is absolutely ridiculous. Please fix the disparate packages nightmare !
This has been fixed in the v4.0 alpha's on the MyGet feed
Thank you onovotny. Great!
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.
@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?
@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?
Can you try with NuGet. I don't know what Paket is doing and how that might impact generation of binding redirects.
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).
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
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.
Hi, I am having this problem after migrating from packages.config to project references? is there any fix please?
We are close to releasing 4.0. Can you please try the latest version on NuGet?
Most helpful comment
Agreed. This is situation is absolutely ridiculous. Please fix the disparate packages nightmare !