Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1' after upgrading from NEST 7.11 to 7.14

[appbbs]

NEST/Elasticsearch.Net version: 7.14.0

Elasticsearch version: 7.3.2

.NET runtime version: 4.8

Operating system version: Windows Server 2019

Description of the problem including expected versus actual behavior:
System.TypeInitializationException
HResult=0x80131534
Message=The type initializer for 'PerTypeValues1' threw an exception. Source=Elasticsearch.Net StackTrace: at Elasticsearch.Net.Extensions.NameValueCollectionExtensions.ToQueryString(NameValueCollection nv) at Elasticsearch.Net.RequestData.CreatePathWithQueryStrings(String path, IConnectionConfigurationValues global, IRequestParameters request) at Elasticsearch.Net.RequestData..ctor(HttpMethod method, String path, PostData data, IConnectionConfigurationValues global, IRequestParameters local, IMemoryStreamFactory memoryStreamFactory) at Elasticsearch.Net.Transport1.Request[TResponse](HttpMethod method, String path, PostData data, IRequestParameters requestParameters)
at Nest.ElasticClient.Search[TDocument](ISearchRequest request)

Inner Exception 1:
FileLoadException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Steps to reproduce:
1.
2.
3.

Expected behavior
It should not ask for System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1 but use Version=5.0.0

Provide ConnectionSettings (if relevant):

Provide DebugInformation (if relevant):

[stevejgordon]

Hi @appbbs. Thanks for raising this. I've narrowed it down to this performance improvement PR #5731. It depends on System.Memory 4.5.4, the latest release, which itself depends on System.Runtime.CompilerServices.Unsafe => 4.5.3. Unfortunately, it seems that the package had a bug affecting binding redirects, fixed in 4.6.0.

When I create a new .NET 4.8 app with NEST included, System.Runtime.CompilerServices.Unsafe 5.0.0 is transiently resolved and used. Do you reference System.Runtime.CompilerServices.Unsafe directly in your application? I suspect another package you use is resulting in the conflict here.

Unfortunately, this is really a bug in the framework and the package that you're running into. We have some options such as removing this fix (and reference) entirely for .NET Fx or looking at manually raising the dependency by also referencing System.Runtime.CompilerServices.Unsafe. Both are not ideal options as this will generally not affect consumers until they run into a conflict.

This issue also affected some of the StackOverflow packages and Nick wrote up a useful post explaining the issue and some potential workarounds you could try. Would you mind letting me know if any of those help in your case?

[appbbs]

Hi @stevejgordon . Thanks for the reply. I double checked and find that System.Runtime.CompilerServices.Unsafe 5.0.0 is used by System.Diagnostics.DiagnosticSource:
https://github.com/elastic/elasticsearch-net/blob/7.14.0/src/Elasticsearch.Net/packages.lock.json#L42
So here is the problem, System.Diagnostics.DiagnosticSource and System.Memory are all required by Elasticsearch.Net 7.14. However one of them requires System.Runtime.CompilerServices.Unsafe 5.0.0, the other one requires System.Runtime.CompilerServices.Unsafe 4.5.3, which leads to the conflict. I could definitely use binding redirect. But In my opinion, it will be better to remove the fix you mentioned above because it may cause more trouble in the future.

[stevejgordon]

Hi @appbbs. I don't think it's quite so simple, unfortunately. DiagnosticSource itself depends on System.Memory >= 4.5.4 as well. Having reviewed this, I think dropping the dependency is a little premature, although if we see others reporting this, or upvoting this issue, that could change my mind.

For now, I'd rather see if I can reproduce this state of affairs and/or we can provide guidance on dealing with the rather annoying case of glitchy packages and binding redirect behaviour.

In a brand new .NET 4.8 project, after adding NEST I see the following in packages.config:

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Elasticsearch.Net" version="7.14.1" targetFramework="net48" />
  <package id="Microsoft.CSharp" version="4.6.0" targetFramework="net48" />
  <package id="NEST" version="7.14.1" targetFramework="net48" />
  <package id="System.Buffers" version="4.5.1" targetFramework="net48" />
  <package id="System.Diagnostics.DiagnosticSource" version="5.0.0" targetFramework="net48" />
  <package id="System.Memory" version="4.5.4" targetFramework="net48" />
  <package id="System.Numerics.Vectors" version="4.5.0" targetFramework="net48" />
  <package id="System.Runtime.CompilerServices.Unsafe" version="5.0.0" targetFramework="net48" />
</packages>

And this is the default app.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.8" />
    </startup>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

I suspect it's that binding redirect that is avoiding the issue in this simple console app.

Would you be able to try updating your project to see if that helps as a potential workaround? Additionally, would you be able to share details of any other packages you depend on, the project type and share your own packages.config and app.config files? I'd like to better understand this by trying to reproduce the problem before we decide on the appropriate steps to solve it.

[stevejgordon]

Hi @appbbs. I just wanted to follow up on my queries above.

Would you be able to try updating your project to see if that helps as a potential workaround? Additionally, would you be able to share details of any other packages you depend on, the project type and share your own packages.config and app.config files? I'd like to better understand this by trying to reproduce the problem before we decide on the appropriate steps to solve it.

[VaDRo]

I have the same issue without any uprgrades. I started my work with Elastic from 7.14 version. I'm receiving this exception when I'm turning debug mode on

           var node = new Uri(_settings.ElasticSearchEndpoint);
                _connectionSettings = new ConnectionSettings(node)
                    .EnableDebugMode();
                _client = new ElasticClient(_connectionSettings);

Exception will be fired at the moment of index deletion:

            if (_client.Indices.Exists(indexName).Exists)
            {
                _client.Indices.Delete(indexName);
            }

If I comment initialization of debug mode -> exception will be gone

[stevejgordon]

@VaDRo Thanks for providing this information. Are you able to confirm your .NET runtime version please, and if possible, share details of any other packages your project references? Does the binding redirect mentioned above prevent the exception from occurring?

[VaDRo]

Good day,Steve.
.NET Framework 4.8
Other packages:

• AWS SDK
• BouncyCastle.CryptoExt
• Dapper
• Elasticsearch.NET
• HtmlAgilityPack
• LeanSentry (AppMon)
• log4net
• MailKit
• MicrosoftPractices libraries
• Redis
• MimeKit
• MiniProfiler
• Nest
• Newtonsoft.JSon
• SshNet
  Maybe that's it
  I haven't tried binding redirect yet

[harrallo]

In case it helps anyone: we were getting the same error upgrading elastic search to 7.16. in our .NET project. The trouble was that we were referencing the elastic and nest libraries in one of our libraries, and then referencing our library in the main executable project. In this case the binding redirect needs to be in the main executable project config, not in the library's config. Also, it seems advisable to add a reference to the "System.Runtime.CompilerServices.Unsafe.dll" to the main executable project if you use automatic building, otherwise msbuild may not copy it to the output directory.

[stevejgordon]

Binding redirects in general are a bit broken in .NET Framework as we've touched on in this thread. I don't believe there's much we can do in the client library to resolve this, beyond the workarounds already highlighted. I'm going to close this on that basis.