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 #27774
Comments
|
I've shared a msbuild.binlog at |
|
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(); |
|
@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: dotnet/standard#481 (comment) |
|
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? |
|
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? |
|
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. |
|
fusion logs are shared at Edit: fixed the share location |
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.
|
|
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
The config files I saw from fuslog are |
|
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 Here is the stack trace: " at Microsoft.AspNetCore.Http.Connections.NegotiateProtocol.ParseResponse(Stream content)\r\n at Microsoft.AspNetCore.Http.Connections.Client.HttpConnection.d__44.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Microsoft.AspNetCore.Http.Connections.Client.HttpConnection.d__51.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Microsoft.AspNetCore.Http.Connections.Client.HttpConnection.d__43.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Microsoft.AspNetCore.Http.Connections.Client.HttpConnection.d__40.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Microsoft.AspNetCore.Http.Connections.Client.HttpConnection.d__39.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Microsoft.AspNetCore.SignalR.Client.HttpConnectionFactory.d__3.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at Microsoft.AspNetCore.SignalR.Client.HttpConnectionFactory.d__3.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Microsoft.AspNetCore.SignalR.Client.HubConnection.d__47.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at Microsoft.AspNetCore.SignalR.Client.HubConnection.d__39.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.GetResult()\r\n at GTA.PushNotifications.SignalRCore.Helpers.SignalRPushNotificationHelper.d__4`2.MoveNext()" |
|
any solution you have got for this? |
|
@ashuthinks do you mind sharing your msbuild.binlog so that we can better analyze what is going on? to generate one, please run |
|
@ashuthinks try to update all nuget packets in client poject. This worked for me. |
|
I am encountering exactly the same issue with Unity3d client. |
|
I have the exact same problem, I tried everything I could find on the internet i'm completely clueless now.. |
maryamariyan
added
the
untriaged
|
Same issue observed on upgrading project to .NET framework 4.7.2 even after upgrading all nuget packages. Error: ======== ============ Below is my app.config file |
|
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. |
|
Same related issue raised by me |
@joperezr 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. |
|
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 |
|
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 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:
|
|
@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: |
|
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... |
|
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 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, Indeed, the error message when opening the web page is 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: 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! |
|
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 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. |
|
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: 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: Example: It will still try to load the following assembly: Instead of: Anyone have any idea how I can solve this problem? |
|
@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. |
|
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. |
|
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. |
ViktorHofer
removed
the
untriaged
|
Have same issue with .NET Framework 4.8 project referencing System.Buffers indirectly as dependency of System.IO.Pipelines and System.Memory packages... |
|
I was having the System.Buffers, Version=4.0.2.0 problem with add-in that a pre-existing program loads. Finally, it was solved by @sean-mcl 's idea here. When *.exe.config had the bindingRedirect, then it was solved. Thank you! |
Have you solved this problem? I've meet the same issue with .NET Framework 4.8 and indirectly reference. It suddenly not work for deployment but works on both debug and release. |
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.bin\Debugdirectory has 41 filesTestResults\<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)Actual:
The text was updated successfully, but these errors were encountered: