2

I recently upgraded my console app project from framework 4.5.2 to 4.6.1. Everything works correctly in the development environment, but when I deploy the full bin folder to my production environment, I get the following error.

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'System.IO.Pipelines, Version=4.6.26919.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I have setup the binding redirect in production as follows:

  <dependentAssembly>
    <assemblyIdentity name="System.IO.Pipelines" publicKeyToken="cc7b13ffcd2ddd51" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.6.26919.2" />
  </dependentAssembly>

The file definitely exists in the bin folder and my production environment has framework 4.6.2 installed. Any ideas?

Updated with output from FUSLOGVW:

*** Assembly Binder Log Entry  (1/2/2019 @ 11:47:22 AM) ***

The operation failed.
Bind result: hr = 0x80131040. No description available.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable  {{REDACTED}}\NotificationService.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = System.IO.Pipelines, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
 (Fully-specified)
LOG: Appbase = file:///{{REDACTED}}/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NotificationService.exe
Calling assembly : Pipelines.Sockets.Unofficial, Version=1.0.0.0, Culture=neutral, PublicKeyToken=42ea0a778e13fbe2.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: {{REDACTED}}\NotificationService.exe.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: System.IO.Pipelines, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///{{REDACTED}}/System.IO.Pipelines.DLL.
LOG: Assembly download was successful. Attempting setup of file: {{REDACTED}}\System.IO.Pipelines.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: System.IO.Pipelines, Version=4.0.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
fizch
  • 2,599
  • 3
  • 30
  • 45
  • 1
    Try removing the `bindingRedirect`. – Robert Harvey Jan 02 '19 at 17:15
  • @RobertHarvey that is how it started. I added it because I was getting the same message except for the version was 4.0.0.0 – fizch Jan 02 '19 at 17:19
  • 1
    Use Microsoft's "Assembly binding log viewer" (Fuslogvw.exe), it tells you what binding requests are being processed and which fail. https://learn.microsoft.com/en-us/dotnet/framework/tools/fuslogvw-exe-assembly-binding-log-viewer – Siraf Jan 02 '19 at 17:27
  • 1
    @maytham-ɯɐɥʇʎɐɯ that isn't referenced directly in my package manager. It is a dependency of StackExchange.Redis. – fizch Jan 02 '19 at 17:28
  • @Siraf is that something that I can run on my server without installing Visual Studio? – fizch Jan 02 '19 at 17:33
  • Yes, check this: https://stackoverflow.com/questions/1012252/using-fuslogvw-exe-on-a-machine-with-no-visual-studio-installed – Siraf Jan 02 '19 at 17:35
  • @Siraf updated with the output from fuslogvw – fizch Jan 02 '19 at 18:04
  • There you go, it seems that you are redirecting to version 4.0.0.0, in your environment there is 4.0.0.1 NOT 4.0.0.0 – Siraf Jan 02 '19 at 18:10
  • @Siraf that did it. Can you create that as an answer? – fizch Jan 02 '19 at 18:13
  • @fizch I noticed you seem to have resolved your problem due to your understanding of the logs there. But what was the actual resolution in your codebase that fixed it? (asking for a friend) – Nieminen Jul 15 '20 at 12:49
  • @Nieminen you need to set the old version referenced in binding redirect to include the highest version. You would use the fuslogvw that is mentioned in the answer to actually tell what that version number is. – fizch Jul 26 '20 at 15:16

1 Answers1

3

Use Microsoft's "Assembly binding log viewer" (Fuslogvw.exe), it tells you what binding requests are being processed and which fail.

https://learn.microsoft.com/en-us/dotnet/framework/tools/fuslogvw-exe-assembly-binding-log-viewer

If fuslogvw.exe is not installed on the production environment then check this: using FUSLOGVW.EXE on a machine with no Visual Studio installed

Siraf
  • 1,133
  • 9
  • 24
  • 2
    This worked. It allowed me to see that it found 4.0.0.1 not the file version that I had set it to. Thanks for your help. – fizch Jan 02 '19 at 18:17