Runtime: Error loading System.Buffers, Version=4.0.2.0 when using AspNet Core SignalR C# client in a .NET Framework 4.7.1 Web test
- clone to get the signalr chat sample at https://github.com/aspnet/SignalR-samples/tree/master/ChatSample
- open the solution, restore nuget package and Ctrl+F5 to run the service
- clone the webtest repro project at https://github.com/jeremymeng/WebTestRepro
- open
WebAndLoadTestProject2.sln, restore then build the project. You will need the web test payload for your visual studio installation to support this type of project.
- notice that the
bin\Debugdirectory has 41 files - now open the webtest.webtest file in visual studio. select Debug Test, pause before starting from the drop down
- under web test solution folder, check the most recent
TestResults\<user_machineName timestamp>\Outfolder. This is where the test is actually running. The folder only has 25 files under it. (This could be a bug in Web Test framework. I already logged a separate internal bug against VSTT team) - copy all files from bin\Debug folder into the Out folder (skip existing)
- click Run button (the first button) to continue the web test
Actual:
System.IO.InvalidDataException
HResult=0x80131501
Message=Invalid negotiation response received.
Source=Microsoft.AspNetCore.Http.Connections.Common
StackTrace:
at Microsoft.AspNetCore.Http.Connections.NegotiateProtocol.ParseResponse(Stream content)
at Microsoft.AspNetCore.Http.Connections.Client.HttpConnection.<NegotiateAsync>d__45.MoveNext()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Http.Connections.Client.HttpConnection.<GetNegotiationResponseAsync>d__52.MoveNext()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Http.Connections.Client.HttpConnection.<SelectAndStartTransport>d__44.MoveNext()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Http.Connections.Client.HttpConnection.<StartAsyncCore>d__41.MoveNext()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Http.Connections.Client.HttpConnection.<StartAsync>d__40.MoveNext()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.SignalR.Client.HttpConnectionFactory.<ConnectAsync>d__3.MoveNext()
at Microsoft.AspNetCore.SignalR.Client.HttpConnectionFactory.<ConnectAsync>d__3.MoveNext()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.SignalR.Client.HubConnection.<StartAsyncCore>d__31.MoveNext()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.SignalR.Client.HubConnection.<StartAsync>d__24.MoveNext()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at iRel8.Service.WebTests.WebtestPlugins.SignalRJoinRoomPlugin.<PreRequest>d__0.MoveNext() in C:\github\jeremymeng\WebTestRepro\WebAndLoadTestProject2\SignalRJoinRoomPlugin.cs:line 16
Inner Exception 1:
TypeInitializationException: The type initializer for 'JsonArrayPool`1' threw an exception.
Inner Exception 2:
FileNotFoundException: Could not load file or assembly 'System.Buffers, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
jeremymeng
All 36 comments
I've shared a msbuild.binlog at \\scratch2\scratch\yumeng\WebTestRepro\msbuild.binlog
jeremymeng
on 30 Oct 2018
same test code runs find in a 4.7.1 WPF app
var baseUrl = "http://localhost:15935";
var connection = new HubConnectionBuilder()
.WithUrl($"{baseUrl}/chat")
.Build();
await connection.StartAsync();
cc @joperezr @wtgodbe
karelz
on 31 Oct 2018
@jeremymeng this could be related to https://github.com/dotnet/corefx/issues/30642. There's currently a lot of trouble with wrong binding redirects being added by NuGet. I have made a list of related issues: https://github.com/dotnet/standard/issues/481#issuecomment-429643615
GSPP
on 31 Oct 2018
I believe that what might be happening here is that the right binding redirects are not being added as System.Buffers might be an implementation-only dependency. In order to check if this is the case, @jeremymeng do you mind running fuslogvw when the error happens so that we can check who is trying to load System.Buffers? Also, do you have any binding redirects present in your App.config?
joperezr
on 31 Oct 2018
Actually now that I have tried to repro this, I do have a binding redirect created for me for System.Buffers so I can't really repro this. I've also just checked in your binlog and it looks like there was a binding redirect suggested as well for System.Buffers that would have fixed this. Do you have auto binding redirects turned on?
joperezr
on 31 Oct 2018
I have tried with auto binding redirects on/off but didn't see any difference. Where did you see the binding redirect created? In my webtest project I don't see any app.config or web.config.
jeremymeng
on 31 Oct 2018
fusion logs are shared at \\scratch2\scratch\yumeng\fuslogs. The error for System.Buffers
LOG: Attempting download of new URL file:///C:/github/jeremymeng/WebTestRepro/TestResults/yumeng_YU-Z230 2018-10-31 10_03_52/Out/System.Buffers.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\github\jeremymeng\WebTestRepro\TestResults\yumeng_YU-Z230 2018-10-31 10_03_52\Out\System.Buffers.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: System.Buffers, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
WRN: Comparing the assembly name resulted in the mismatch: Build Number
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
Edit: fixed the share location
jeremymeng
on 31 Oct 2018
Where did you see the bidning redirect created?
If you check the ResolveAssemblyReferences target, RAR noticed there was a conflict with the versions of System.Buffers so it suggested a binding redirect that will force the 4.0.3 version to be loaded (which is the one that you found according to the fuslog). If you have auto binding redirects turned on, then we should be adding these binding redirects that RAR suggested into your resulting config file (meaning the one located at bin/Debug. If this is a web project, then when turning auto generate binding redirects on you should get a warning when building telling you you need some redirects, which when double clicking the warning should add them to your web.config.
joperezr
on 31 Oct 2018
My project is a WebTest project (Output Type of Class Library). I don't get any warnings or errors when building the project in Visual Studio. There are no *.config files under bin\Debug even I have auto generate binding redirects on
1>CopyFilesToOutputDirectory:
1> Copying file from "obj\Debug\WebAndLoadTestProject2.dll" to "bin\Debug\WebAndLoadTestProject2.dll".
1> WebAndLoadTestProject2 -> C:\github\jeremymeng\WebTestRepro\WebAndLoadTestProject2\bin\Debug\WebAndLoadTestProject2.dll
1> Copying file from "obj\Debug\WebAndLoadTestProject2.pdb" to "bin\Debug\WebAndLoadTestProject2.pdb".
1>
1>Build succeeded.
1> 0 Warning(s)
1> 0 Error(s)
1>
1>Time Elapsed 00:00:00.41
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
The config files I saw from fuslog are
LOG: Using application configuration file: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\QTAgent32_40.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
I am having this exact same problem. I am running the ASP.NET Core Client code in a Standard 2.0 Library and referencing it from a IIS Web framework application (4.7.2). I have tried everything from adding binding redirects to removing all references.
When calling SendAsync using ASPNetCore signalr
I'm getting "Invalid negotiation response received."
Inner exception:
"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. (Exception from HRESULT: 0x80131040)"
Here is the stack trace:
" at Microsoft.AspNetCore.Http.Connections.NegotiateProtocol.ParseResponse(Stream content)\r\n at Microsoft.AspNetCore.Http.Connections.Client.HttpConnection.
mgoldhgb
on 30 Mar 2019
any solution you have got for this?
I'm also facing the same issue.
ashuthinks
on 12 Apr 2019
@ashuthinks do you mind sharing your msbuild.binlog so that we can better analyze what is going on? to generate one, please run msbuild yourProject.csproj /t:rebuild /bl and I'll take a look. If you could also share the contents of your App.config file in case you have one, that would be valuable.
joperezr
on 12 Apr 2019
@ashuthinks try to update all nuget packets in client poject. This worked for me.
AleXr64
on 12 Apr 2019
I am encountering exactly the same issue with Unity3d client.
StanislavChankov
on 11 Aug 2019
I have the exact same problem, I tried everything I could find on the internet i'm completely clueless now..
Rakiah
on 3 Jan 2020
Same issue observed on upgrading project to .NET framework 4.7.2 even after upgrading all nuget packages.
Error:
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. (Exception from HRESULT: 0x80131040) 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. (Exception from HRESULT: 0x80131040)
========
Even getting same error after upgrading System.Buffers to available versions on nuget 4.0.0/ 4.3.0 / 4.4.0 / 4.5.0
============
Below is my app.config file
connectArun2001
on 3 Mar 2020
There is a new version of System.Buffers package that will ship some time this month which will make most of these problems go away. Package version will be 4.5.1.
joperezr
on 3 Mar 2020
Same related issue raised by me
Geting Error after Migrate from packages.config to PackageReference #9249
connectArun2001
on 4 Mar 2020
There is a new version of System.Buffers package that will ship some time this month which will make most of these problems go away. Package version will be 4.5.1.
@joperezr Is there any information as to why 4.5.0 is causing issues?
cameron-pascal
on 13 Mar 2020
Is there any information as to why 4.5.0 is causing issues?
The error people get when they hit this is just a symptom, and unfortunately it is a symptom that may be caused by many different root causes. The most common case why people hit this issue is because they are targetting .NET Framework in their app, and for one reason or another the tooling isn't fully detecting that System.Buffers implementation targets .NET Standard, or it may detect it but it won't include the required facades in the bin output folder because of custom project settings. That means that if you try to summarize most problems really happen because System.Buffers implementation targets .NET Standard, so what we did different in 4.5.1 was to provide an implementation in the package that also targets .NET Framework. With this, most projects that were having custom logic or settings causing this problem to arise should be fixed.
joperezr
on 13 Mar 2020
We tried referencing the System.Buffers 4.5.1 package directly in the ASP.NET web project, and no luck, we still end up with the error. Anything we can do to help diagnose what the problem is? It prevents us from using MessagePack currently and we don't know how to work around this. When we manually extract the nugget package, the System.Buffers.dll in the net461 folder and the netstandard2.0 folder both fail with Could not load file or assembly 'System.Buffers, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.). What's next?
christianrondeau
on 3 Apr 2020
Do you have a simple repro I could take a look at? If you have added a dependency to the new package, then it is possible that there is a problem with 1) the binding redirects are not being generated or 2) the right System.Buffers.dll is not present right next to the application that is trying to be executed. How are you running the app? Is it out of the bin folder or are you doing some sort of deployment?
joperezr
on 3 Apr 2020
@joperezr I have created this project, which contains near the minimum: https://github.com/christianrondeau/dotnet-runtime-issue-27774 - the link include steps to reproduce (I reproduced using an ASP.NET 4.7.2 project since that's our use case but as far as I know this may also happen with console app)
The important part:
- In
project/Project.csproj:
- Reference
MessagePack(System.Buffers 4.5.0) - Reference
Microsoft.AspNetCore.Http.Extensions(built-inSystem.Buffers)
- Reference
- In
web/Web.csproj
- Reference
System.Buffers 4.5.1(or no, it doesn't seem to change anything)
- Reference
christianrondeau
on 6 Apr 2020
@christianrondeau I see what the problem is here. It seems like you need a binding redirect since there are two versions of System.buffers used in your project, 4.0.2.0 and 4.0.3.0 (which the latter is the one that ends up in your bin folder). The problem is that because your project type (web project) isn't an executable, MSBuild will not generate binding redirects for you by default. If you set the following property in your Web.csproj this issue should be resolved:
<PropertyGroup>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
Doing this should do that in your web/bin folder, you will now see a Web.dll.config, and this will instruct the loader that if the version 4.0.2.0 of System.Buffers is requested, it should just allow to use 4.0.3.0 instead. Let I don't have IIS on my machine so I can't validate this, but please try it and let me know if that works. Also as an aside, it looks like this web project you created is not really a web sdk project which might be why we are not detecting you need binding redirects, a SDK Web project usually starts with: <Project Sdk="Microsoft.NET.Sdk.Web">
joperezr
on 6 Apr 2020
I tried both adding the SDK to the Web.csproj and adding the GenerateBindingRedirectsOutputType (pushed in the github repro if you want to double check), same issue...
christianrondeau
on 6 Apr 2020
Then it means that the host process you are using is not respecting the dll.config when loading your assembly. In this case I would recommend using https://docs.microsoft.com/en-us/dotnet/framework/tools/fuslogvw-exe-assembly-binding-log-viewer in order to diagnose who is failing to load the assembly, and why is the dll.config not being taken into account. FusLogVW has all that info and is very easy to use.
joperezr
on 6 Apr 2020
@joperezr Thanks for helping. I tried simplifying the project, now it's simply a web project that references MessagePack and System.Buffers 4.5.1, nothing else. Got the same problem.
I attached the full log here: https://raw.githubusercontent.com/christianrondeau/dotnet-runtime-issue-27774/master/System.Buffers.4.5.1.Fusion.log
As expected, w3wp.exe is the executable, and it indeed tries to get the assembly from the bin folder. But it fails with:
LOG: Assembly Name is: System.Buffers, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
WRN: Comparing the assembly name resulted in the mismatch: Build Number
Indeed, the error message when opening the web page is Could not load file or assembly 'System.Buffers, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies..
Running with System.Buffers 4.5.0 instead gives this output: https://raw.githubusercontent.com/christianrondeau/dotnet-runtime-issue-27774/master/System.Buffers.4.5.0.Fusion.log
This looks very similar to #27492 and maybe #27470 though I'm not sure. Adding this works:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Buffers" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.0.2.0" newVersion="4.0.3.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
But as discussed in the other issues, this is normally something we shouldn't have to do.
Looking forward to hearing your thoughts. If you want you can check again the reproduction github project, it's now a single project with two references, and that's it. Thank you!
christianrondeau
on 7 Apr 2020
Yeah given that this is a web project, looks like the binding redirect needs to be in the web.config. The property I told you before would only generate that binding redirect on a web.dll.config not on the the web.config file which according to the binlog that is what is being respected. In any case, I think the issue you are hitting is not related to System.Buffers itself, but instead should be logged either in aspnet repo (given that this is something that would only happen on web projects) or on msbuild/sdk repos (given those are the ones that can detect the assembly mismatch problem and perhaps can do something about adding the right binding redirect to the web.config). You happen to hit this with the System.Buffers package, but there is nothing special about it that is causing this, simply that there are two assemblies in your closure that depend on different versions of it, but you could have easily just get a repro the same with other packages like Newtonsoft.Json for example.
joperezr
on 7 Apr 2020
@joperezr that's possible, I know that we are referencing a _lot_ of projects and only System.Buffers had to be rebound (I attached the list of transitive dependencies here: https://raw.githubusercontent.com/christianrondeau/dotnet-runtime-issue-27774/master/SampleProject.Dependencies.txt)
This being said I do not have the knowledge for knowing what issue to open and where, only that an ASP.NET project running in IIS fails automatically rebinding when System.Buffers (at least that's the only one I could see) is present.
If this is normal behavior and it is expected that we do manual rebinding, then that's what I'll do and I guess this is a "known issue" working with Asp.Net and .NET Framework 4.7.2 along with netstandard2.0.
If this is not normal behavior, then I will need help creating the issue since I'm not clear on the internals; unless you'd like to transfer it yourself. Hopefully the reproduction project is simple enough for experts on your end to identify how to move forward.
In any case if I can be of any help, please let me know. At the moment we will move forward with rebinding, but I'm available if there's something I can do.
christianrondeau
on 7 Apr 2020
Okay. We've identified a similar problem.
The goal was to integrate an ASP.NET Core 2.1 application based on Framework 4.7.2 into our existing application.
To do this, we created a project using the ASP.NET Core web application template.
We then converted this into a class library and adapted the output paths.
We also added the following entries to the project file:
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
When starting our application, this class is dynamically loaded and the server will be started.
In the bin\debug directory there is also a matching *.dll.config, which maps the redirects of the app properly:
...
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.AspNetCore.Mvc.Core" publicKeyToken="adb9793829ddae60" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.3.0" newVersion="2.1.3.0" />
</dependentAssembly>
</assemblyBinding>
...
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-12.0.0.0" newVersion="12.0.0.0" />
</dependentAssembly>
</assemblyBinding>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<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>
</assemblyBinding>
...
Example:
It will still try to load the following assembly:
System.Buffers, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
Instead of:
System.Buffers, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
Anyone have any idea how I can solve this problem?
sean-mcl
on 4 May 2020
@sean-mcleish the only way we found was to configure reminding in the Web.config file, like this:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<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>
</assemblyBinding>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Still not working.
A *.dll.config is generated with the correct bindingRedirects. But it is completely ignored when the assembly is loaded and he still complains about the versions.
sean-mcl
on 5 May 2020
Okay, I found a temporary solution. The problem was that I dynamically loaded my web class library from a main application. The dynamic loading works by searching for all *.dll that implement a certain interface.
The main application looks at its own *.exe.config and ignores the *.dll.config of the web class library.
The current fix: add the redirects in the app.config of the main application.
The desired fix: the main application also considers the *.dll.configs of all applications.
I need to get a little more information about this.
sean-mcl
on 5 May 2020
Seeing the same error with a project compiled to .NET Framework 4.8. The output folder contains System.Buffers.dll but it's version 4.6.
DiskCrasher
on 19 May 2020
Have same issue with .NET Framework 4.8 project referencing System.Buffers indirectly as dependency of System.IO.Pipelines and System.Memory packages...
tomrus88
on 7 Aug 2020
Related issues
jzabroski
路
3Comments
iCodeWebApps
路
3Comments
jamesqo
路
3Comments
GitAntoinee
路
3Comments
EgorBo
路
3Comments
Most helpful comment
The error people get when they hit this is just a symptom, and unfortunately it is a symptom that may be caused by many different root causes. The most common case why people hit this issue is because they are targetting .NET Framework in their app, and for one reason or another the tooling isn't fully detecting that System.Buffers implementation targets .NET Standard, or it may detect it but it won't include the required facades in the bin output folder because of custom project settings. That means that if you try to summarize most problems really happen because System.Buffers implementation targets .NET Standard, so what we did different in 4.5.1 was to provide an implementation in the package that also targets .NET Framework. With this, most projects that were having custom logic or settings causing this problem to arise should be fixed.