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

Question 1

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.

Question 2

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

Question 3

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..

Question 4

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.

Question 5

How do I configure my solution to honour package.config file in its directory?

To make sure your solution to honor the package.config file in the .nuget folder, you should configure this file correctly, for example, I created a test sample solution, then add a Nuget.config inside .nuget folder:

My NuGet.Config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="D:Test" />
  </config>
</configuration>

Then, another important info is remember restart Visual Studio after adding the Nuget.config file.

As test result, the nuget packages are being restored in 'D:Test' package folder:

Question 6

By default, NuGet creates the solution's packages folder in the solution root, and each project references its package DLLs to that "local" packages folder. In your example, if you open the .csproj file for Project A, you'll probably see that the reference path is something like ..packages[package name][etc].

So when you do a fresh pull from TFS and build solution B, Project A can't find its DLLs because c:workspaceSolution Apackages doesn't exist yet (or whatever the absolute path is on your machine).

To correct this, use a shared package folder, created at c:workspacepackages. To do this, you have to add an additional node to the NuGet.config in each solution (see https://docs.nuget.org/consume/nuget-config-file for details; I am also assuming you have a NuGet folder at c:workspaceSolution A.nuget):

<config>
  <add key="repositorypath" value="....packages" />
</config>

I used a relative path here, but you can use an absolute path as well, and the documentation says you can use %HOME% as well.

Do this, then restart Visual Studio. The next time you open the package manager, it should ask you if you want to restore missing packages, and assuming you click yes, it will put them in the new location. The last step is to edit the .csproj file and change all instances of ..packages to ....packages (or you can uninstall and reinstall the package, but I find editing the .csproj a lot faster).

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

Answers

c#,visual-studio,redis,nuget,servicestack