Search code examples
c#.net-4.8.net-standard-2.0msgpackassembly-binding-redirect

Binding Redirect from System.Buffers 4.0.2.0 to 4.0.3.0 not working on some machines


Bug description

We are using MessagePack in our .NET Framework 4.8 solution. On some of our customers machines, there is a problem with the serialization, especially the usage of System.Buffers. The System.Buffers.dll could not be loaded because the version is a mismatch (MessagePack requires 4.0.2.0; for another NuGet package, we need System.Buffers of version 4.0.3.0). But our App.config has a BindingRedirect that is completely ignored.

Actual behavior

We receive a error at some machines the first time, the MessagePack dll gets loaded.

System.IO.FileLoadException:Could not load file or assembly 'System.Buffers, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

  • Version used: 2.5.108
  • Runtime: .NET Framework 4.8

We created a log to verify that the binding redirect does not work on the machine of the customer . I'll attach the log from a working machine and a not working machine as well as our App.config file.

We copied the installed files from the customers machine to our local, and with the files it worked on our side. Also, the content machine.config file in the .NET Framework folder (C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config) on the working machine is the same as the machine.config on the not working machine - so we can exclude it already as the cause.

Sadly, we don't know how this issue is reproduced. Currently, it affects around 5 customers. One customer has a completely fresh Windows Server 2022 installation where it happens, but we can't reproduce it on a new Server 2022.

Expected behavior

The serialization should work on all machines. The System.Buffers 4.0.3.0 is loaded correctly and the BindingRedirect has to be operational.

Attachments

Binding Redirect in app.exe.config

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

Fuslog - Working machine

...
Aufruf von Assembly : MessagePack, Version=2.5.0.0, Culture=neutral, PublicKeyToken=b4a0369545f0a1be.
===
LOG: Diese Bindung startet im default-Load-Kontext.
LOG: Die Anwendungskonfigurationsdatei wird verwendet: C:\Users\afi\Desktop\customer data\Password Safe and Repository 8 Server\PSRServerAdmin.exe.config
LOG: Die Hostkonfigurationsdatei wird verwendet: 
LOG: Die Computerkonfigurationsdatei von C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config wird verwendet.
LOG: In der Anwendungskonfigurationsdatei wurde eine Umleitung gefunden. 4.0.2.0 wird nach 4.0.3.0 umgeleitet.
LOG: Verweis nach der Richtlinie: System.Buffers, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
...

Fuslog - Customer (Not working machine)

...
Aufruf von Assembly : MessagePack, Version=2.5.0.0, Culture=neutral, PublicKeyToken=b4a0369545f0a1be.
===
LOG: Diese Bindung startet im default-Load-Kontext.
LOG: Die Anwendungskonfigurationsdatei wird verwendet: C:\Program Files\Password Safe and Repository 8 Server\PSRServerAdmin.exe.config
LOG: Die Hostkonfigurationsdatei wird verwendet: 
LOG: Die Computerkonfigurationsdatei von C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config wird verwendet.
LOG: Verweis nach der Richtlinie: System.Buffers, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51

...

Fehler bei diesem Vorgang.
Ergebnis der Bindung: hr = 0x80131040. Keine Beschreibung vorhanden.

...

Solution

  • We found a solution ourself. After another session with a customer which had the problem, we found out, that the issue only happened with our 32 bit application (which uses the Assembly Manager from C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll) The problem did NOT happen with our other 64 bit application (which uses the Assembly Manager from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll).

    Both of our applications (32 bit and 64 bit) are installed in the same directory and use some shared dll's. One of them is MessagePack which references System.Buffers 4.0.2.0

    After we modified the 32 bit application to 64 bit, the issue did not happen anymore on the customers machine.