Could not load file or assembly System.Memory Version=4.0.1.0

[weberms]

Description

File load exception when using Confluent.Kafka 1.5.3 with SystemText.Json 5.0.1

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

How to reproduce

Add Confluent.Kafka and System.Text.Json from Nuget. Try to consume events from Kafka queue. Error is thrown when ConsumerBuilder.Build is called to create IClient instance. .NET Framework 4.7.1 project.

Checklist

Please provide the following information:

• A complete (i.e. we can run it), minimal program demonstrating the problem. No need to supply a project file.
• Confluent.Kafka nuget version.
• Apache Kafka version.
• Client configuration.
• Operating system.
• Provide logs (with "debug" : "..." as necessary in configuration).
• Provide broker log excerpts.
• Critical issue.

[andrewfinnell]

Do we have an update or work around for this issue? This is quite critical for us as well. We'd rather not have to downgrade our System.Memory assembly as that seems to be the only fix.

[mrt181]

This still happens with version 1.6.3 and I had to roll back to version 1.5.2.
I have to use net472 because of a third party library from some vendor.

[wensaint]

i have the same issue, so i roll back to v1.5

[mrt181]

v1.7.0 works with net472 for me

[weberms]

@mhowlett this is still happening with the latest v1.8.2 of the client. Is a fix coming?

[gseddon]

I was able to work around it (with the latest Kafka installed) by adding this to the <runtime> section of my app.config:

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
	  <dependentAssembly>
		<assemblyIdentity name="System.Memory" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral"/>
		<bindingRedirect oldVersion="0.0.0.0-4.5.4.0" newVersion="4.0.1.1"/>
	  </dependentAssembly>
    </assemblyBinding>

[inikulshin]

I think, this issue (and probably also #1184) is caused by 14e0d0e, <SignAssembly>true</SignAssembly> build option.

Maybe, adding <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> will help, as suggested workaround by @gseddon will be automatic. Also, see I really, really need to strong-name, what kinds of issues will I run into?

Update: or <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>?