Asked  4 Months ago    Answers:  5   Viewed   835 times

I created a Visual Studio (Community 2019) project with C# using ServiceStack.Redis. Since it is C#, I use Windows 10 (there is a Redis version for Windows but it is really old and as I know, it is unofficial so I am afraid that might be the problem). Here is an excerpt from my code:

public class PeopleStorage: IDisposable
{
    public PeopleStorage()
    {
        redisManager = new RedisManagerPool("localhost");
        redis = (RedisClient)redisManager.GetClient();
        facts = (RedisTypedClient<List<Fact>>)redis.As<List<Fact>>();
    }

    public List<Fact> GetFacts(int id)
    {
        string sid = id.ToString();
        if (facts.ContainsKey(sid))
            return facts[sid];
        return accessor.GetFacts(id);
    }

    private RedisTypedClient<List<Fact>> facts;
    private RedisClient redis;
    private RedisManagerPool redisManager;
}

In an attempt to connect to Redis in line return facts[sid];, an exception occurs:

System.IO.FileLoadException: "Could not load file or assembly "System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" or one of it's dependences. The found Assembly's manifest definition does not match the Assembly reference. (Exception from HRESULT: 0x80131040)"

(May be inaccurate as I have translated it)

I have tried updating all the packages, starting with ServiceStack packages, ending with System.Runtime.CompilerServices.Unsafe itself. Moreover, you can't choose 4.0.4.1 version in NuGet, the closest one there is 4.0.0, while the relevant is 4.0.7.

I do not understand why it uses this version and how I can fix this problem.
Even a clean reinstall of Visual Studio did not help.

 Answers

86

Could not load file or assembly System.Runtime.CompilerServices.Unsafe

It seems that you have installed System.Runtime.CompilerServices.Unsafe nuget package 4.5.3 version. And it corresponds to System.Runtime.CompilerServices.Unsafe.dll assembly version 4.0.4.1.

Suggestion

1) Please try to register System.Runtime.CompilerServices.Unsafe version 4.0.4.1 into GAC so that the system can it.

  • Run Developer Command Prompt for VS2019 as Administrator

  • type:

    cd xxxxx (the path of the the System.Runtime.CompilerServices.Unsafe 4.0.4.1)
    
    gacutil /i System.Runtime.CompilerServices.Unsafe.dll
    

2) If you use Net Framework projects with xxx.config file, you could use bindingRedirect.

Add these in app.config file or web.config file:

<configuration>  
   <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-4.0.4.1"  
                             newVersion="4.0.4.1"/>  
         </dependentAssembly>  
      </assemblyBinding>  
   </runtime>  
</configuration> 

Besides, if you update System.Runtime.CompilerServices.Unsafe nuget package version to the newer version, you should also changed the bindingRedirect assembly version.

You can refer to these assembly versions of System.Runtime.CompilerServices.Unsafe

4.5.x is System.Runtime.CompilerServices.Unsafe nuget package version while 4.0.x.x is System.Runtime.CompilerServices.Unsafe.dll assembly version.

4.5.0 is 4.0.4.0 
4.5.1 is 4.0.4.0 
4.5.2 is 4.0.4.0 
4.5.3 is 4.0.4.1
4.6.0 is 4.0.5.0
4.7.0 is 4.0.6.0
4.7.1 is 4.0.6.1
Friday, June 25, 2021
 
shin
answered 4 Months ago
96

Ok, I think I got it to work now. I deleted every Newtonsoft.Json.dll on my machine that wasn't the latest version that I could find, made sure I had the latest version in NuGet, and build it and made sure that was the latest one in the bin folder, and I left the changes in the web.config and the .csproj. Now I'm on to another error, so it must be working..

Wednesday, June 2, 2021
 
tiny
answered 5 Months ago
35

Seems to be a problem with the current version of automapper:

AutoMapper 5.0.0 Tuesday, June 28, 2016

I tried with the previous version and it works:

PM> Install-Package AutoMapper -Verbose
Install-Package : 'AutoMapper' already has a dependency defined for 'Microsoft.CSharp'.
At line:1 char:16
+ Install-Package <<<<  AutoMapper -Verbose
    + CategoryInfo          : NotSpecified: (:) [Install-Package], InvalidOperationException
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.InstallPackageCommand

PM> Install-Package AutoMapper -Version 4.2.1
Installing 'AutoMapper 4.2.1'.
Successfully installed 'AutoMapper 4.2.1'.

So, if you can't update NuGet Package Manager, the answer is:

PM> Install-Package AutoMapper -Version 4.2.1
Thursday, June 17, 2021
 
liquidmotion
answered 4 Months ago
79

WARNING: Out of Date

As of 2018, this answer is out of date - see my other answer for updated information.

No Nuget Equivalent of maven SNAPSHOTs

NuGet doesn't really support SNAPSHOT dependencies like Maven does, although there is an open issue to implement something similar and a discussion about such functionality.

A possibility suggested was to write a script to:

  • Generate a new Foo package with a different version
  • Update Bar to reference the latest version of Foo

An Alternative Approach

Alternatively when I work on my own projects, I always build and reference Foo from source. Then, once Foo project becomes stable enough that I don't update it much anymore, I then start stop referencing Foo via source and instead build it and reference as a nuget package.

Thursday, August 19, 2021
 
motanelu
answered 2 Months ago
87

Check the AppDomain.AssemblyResolve event. It's the ideal point where you may peform a custom action to load an assembly in a non-default location.

I add here a quote of linked MSDN article:

It is the responsibility of the ResolveEventHandler for this event to return the assembly that is specified by the ResolveEventArgs.Name property, or to return null if the assembly is not recognized. The assembly must be loaded into an execution context; if it is loaded into the reflection-only context, the load that caused this event to be raised fails.

At the end of the day, this means that your application or service will enter into the AssemblyResolve event case when an assembly couldn't be loaded using default assembly discovery approach (AppDomain.BaseDirectory, Global Assembly Cache...).

Once the so-called event is raised, you need to return an instance of Assembly and it's your job deciding how to load the assembly (from file, stream, bytes...). That is, if you're placing your plugin assemblies in some sub-directory or who knows where, you can call Assembly.Load with the right full assembly path to load them and avoid your assembly loading issues.

Monday, August 30, 2021
 
Crontab
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :
 
Share