Stackexchange.redis: System.Buffers, Version=4.0.2.0 error with "Azure Functions" (DOT NET)

Created on 24 Sep 2018  路  12Comments  路  Source: StackExchange/StackExchange.Redis

I am writing to report an error I a facing while trying to connect to Redis Server from Azure function developed in VS2017 (DOT NET). I am using StackExchange.Redis 2.0.505. with Azure Redis basic plan for development. Redis server on Azure portal working fine. I am getting this error on flowing call.
cacheDb.SetAdd(loginUser.Id.ToString(),JsonConvert.SerializeObject(loginUser));

It seems to me reference issue with "System.Buffers" however, unit-tests are working fine, it's just "Azure Functions" throwing an exception.
StackExchange.Redis>>Pilelines.Sockets.unofficial has a reference of System.Buffer. of 4.5 whereas process required 4.0.2.0

Here are a detail error and stack trace:

Error Message: No connection is available to service this operation: SADD 1b4490c0-55f4-400c-b4f6-869ddb2664eb; 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.; IOCP: (Busy=0,Free=1000,Min=8,Max=1000), WORKER: (Busy=2,Free=1021,Min=8,Max=1023), Local-CPU: n/a

Stack: No connection is available to service this operation: SADD 1b4490c0-55f4-400c-b4f6-869ddb2664eb; 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.; IOCP: (Busy=0,Free=1000,Min=8,Max=1000), WORKER: (Busy=2,Free=1021,Min=8,Max=1023), Local-CPU: n/a

Inner Exception level 1
Message: SocketFailure on timetrialdev.redis.cache.windows.net:6379/Subscription, Initializing, last: NONE, origin: ConnectedAsync, outstanding: 0, last-read: 0s ago, last-write: 0s ago, unanswered-write: 892907s ago, keep-alive: 60s, state: Connecting, mgr: 10 of 10 available, last-heartbeat: never, global: 0s ago, v: 2.0.505.18761

Stack:

Inner Exception level 2
Message: 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.

Stack:
at System.IO.Pipelines.PipeCompletion.AddCallback(Action2 callback, Object state) at System.IO.Pipelines.Pipe.OnReaderCompleted(Action2 callback, Object state)
at System.IO.Pipelines.Pipe.DefaultPipeWriter.OnReaderCompleted(Action`2 callback, Object state)
at Pipelines.Sockets.Unofficial.SocketConnection..ctor(Socket socket, PipeOptions sendPipeOptions, PipeOptions receivePipeOptions, SocketConnectionOptions socketConnectionOptions, String name)
at StackExchange.Redis.PhysicalConnection.d__98.MoveNext()

Most helpful comment

I am on 2.0.519 and still seeing this issue running locally

All 12 comments

Sounds like an assembly bindings redirect issue. What runtime are you targeting / running in here? Is it net46* by any chance?

I hit this issue today - no azure component - just local instance of Redis. We recently upgraded from 4.5.2 to 4.7.2

We are using package reference with nuget and vs2017

@adamstewart1980 the "azure functions" one is a bit of a special case and will have different answers. Can you clarify what runtime / platform you are targeting? This is almost certainly an assembly binding redirect problem, so the question becomes: what didn't get added, and is it just a minor config change?

I'm in the process of pushing out some updates that play with the targets and add explicit dependency checks. If we're having a good day, the new targets (for "unofficial") will make it work; if we're having a less good day, we should at least get a better error message.

Please try with 2.0.510 - now available on nuget. I can't guarantee it is going to work (azure functions v1 has some... features there), but: it might.

K; we've determined that this still wasn't happy (see above) - we've now released 2.0.513 which should (crosses fingers) now play a lot happier.

We think this is resolved in 513

Sorry to report but it doesn't appear to be resolved...

We have a .NET Standard 2.0 caching library used by both classic ASP.NET MVC 4.7.2 apps and .NET Core 2.1 apps, we have been running on 1.2.6 with no problems in the 4.7.2 sphere however .NET Core apps were playing up. So we upgraded the caching library to the latest .513 and that cleared up the .NET Core issues, great! ...however the 4.7.2 apps then threw a bunch of errors.

The assembly for System.Buffers could not be loaded; this usually means a missing assembly binding redirect - try checking this, and adding any that are missing; note that it is not always possible to add this redirects - for example 'azure functions v1'; it looks like you may need to use 'azure functions v2' for that - sorry, but that's out of our control

We played with binding redirects on the 4.7.2 web applications but to no avail, the best we got was a fresh error message so we gave up at that point and rolled back to 1.2.6.

Could not load file or assembly 'System.IO.Pipelines, Version=4.0.0.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)

Looks like I'm not the only one with such problems recently;

I am on 2.0.519 and still seeing this issue running locally

@f2calv I had the same issue and I solved it by Update-Package -reinstall on the library pulling my other library using Stackexchange.Redis

I don't know if it's clear, so, I have:

  1. ServiceA (depends on HelperB)
  2. HelperB (This one uses Stackexchange.Redis)

After everything was updated to latest from Nuget, I went realized ServiceA dependencies had little warnings icons, even when Visual Studio said everything was ok, so after a Update-Package -reinstall in ServiceA everything works and runs.

Hope it helps.

Still occurring in 2.0.601

For reference, I am referencing the cache through a .Net Standard 2.0 library from a .Net Core 2.2 Web API project (which works successfully) and a .Net 4.7.2 Azure Worker Role (which gives the error mentioned in previous comments)

I've found my answer here.

Add assembly redirect

<dependentAssembly> <assemblyIdentity name="System.Buffers" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" xmlns="urn:schemas-microsoft-com:asm.v1"/> <bindingRedirect oldVersion="4.0.2.0-4.0.3.0" newVersion="4.0.3.0" xmlns="urn:schemas-microsoft-com:asm.v1"/> </dependentAssembly>

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nareshkhatri81 picture nareshkhatri81  路  5Comments

deepaknc picture deepaknc  路  5Comments

tombatron picture tombatron  路  4Comments

dardar4 picture dardar4  路  4Comments

BrennanConroy picture BrennanConroy  路  6Comments