C# issue with conflicting .NET Assemblies

Question

I've got C# application that runs fine within Visual Studio, but I've extracted the references from the .csproj, and added the to the GAC as part of my installer.

However, when I run the application, when it invokes one of the references (System.Text.Json) I get an Exception:

"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 its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"

I've got System.Runtime.CompilerServices.Unsafe version 6.0.0 in the references in the .csproj, and it's looks like it's successfully installed by my installer.

I enabled Assembly Bind Failure Logging, and it looks like System.Memory is referring to version 4.0.4.1 of System.Runtime.CompilerServices.Unsafe.

Any tips or suggestions on how I could get the conflict resolved?

Updates:

It's a small application to provide the ability to move a astronomical telescope motor focuser. The tools provided by the vendor lack in some areas, and the SDK is pretty easy to use. My app is just a couple of forms that use the SDK API, and saves/loads named positions.I actually tried to add an app.config containing the following:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
    </dependentAssembly>
</configuration>`

but it still fails with the same exception.

The app.config is in the same directory as the executable, and has the same name (with the .config extension instead of .EXE).

Solved: it looks like I'm making things to hard on myself. Soleil's suggestion of using everything in the bin folder seems to work. I just have to update my installer properly now.

Wait, why are you referencing those directly in your `csproj`? They're part of .NET. You shouldn't need to "install" those anywhere. Also, the GAC is for .NET Framework, not .NET Core. — Etienne de Martel, Apr 28 '23 at 03:37
I added System.Text.Json via nuget. I didn't add the references manually. — Tom, Apr 28 '23 at 10:56
Why don't you just copy the content of your `bin` folder, which contains (a priori) everything you need to make an installer ? you also can publish you app. Custom cooking is not helping here. And any net48 assembly is part of any Windows, so you should have a very small package and you should not include those binaries at all in your installer. Can you try to copy you bin content somewhere and try to run your program from there ? — Soleil, Apr 28 '23 at 23:55
*I've extracted the references from the .csproj, and added them to the GAC as part of my installer* Why on Earth would you do that? Just deploy them with your application. [.net - Why should I NOT use the GAC?](https://stackoverflow.com/a/538786/2791540) — John Wu, Apr 29 '23 at 00:08
@Soleil because I don't know what I'm doing yet ;) Thanks. using the files in the bin folder seems to have done the trick! — Tom, Apr 29 '23 at 01:00

Soleil · Answer 1 · 2023-04-29T15:02:17.470

Since your app runs well from Visual Studio, I recommend you to base your installation package on the target directory, ie., usually bin\Release\net48 if your are targetting net48. Your nuget packages will be copied in the process.

You also can publish you app, or create a ClickOnce package. If you need to create an installer package from your binaries, you might also want to consider NSIS.

Custom cooking is not helping here. In general, you want to keep your devops processes (here you are doing a beginning of deployment) as simple as possible and as automatable (scriptable) as possible, so your devops process requires as little maintenance as possible (this keeps costs lower) as you update your project.

And any net48 assembly is part of any Windows (7 and after I believe), so you should have a very small package and you should not include those binaries at all in your installer.

score 0 · Answer 2 · answered Apr 28 '23 at 11:45

There isn't enough information in the question to be sure, but it sounds like a binding redirect might be needed.

An application (strictly, an appdomain) can only load one version of an assembly. If your application includes multiple references to an assembly, perhaps as dependencies of other packages you have installed, and those references are to different versions of the assembly, you will need to redirect at least one of them so that a common version is used.

You don't say what kind of C# application this is, but you could try adding something like the following to the <assemblyBinding> element of your app.config file (or other file depending on the application type):

  <dependentAssembly>
    <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
  </dependentAssembly>

As mentioned in the comments, you shouldn't need to add anything to the GAC manually. If your application is more complex or might involve multiple appdomains, I would suggest some further reading to understand the reason for the original error before adopting this approach (even if it works).

I've updated my original question, as there was too much to add as a comment. Thanks for the response! — Tom, Apr 28 '23 at 23:33
@Tom I general, as OP, you should answer to questions asking for clarification or more details by updating the OP, not with a comment, so new readers do not have to seek the details in the comments. Well done ! — Soleil, Apr 28 '23 at 23:41
Thanks for the update, Tom, and glad you've got this sorted. Perhaps you could consider accepting the answer by @Soleil if it put you on the right track? — Neil T, Apr 29 '23 at 07:48

C# issue with conflicting .NET Assemblies

2 Answers2