Mismatching versions of System.Text.Json

Question

Mismatching versions of System.Text.Json

uds 25

In our company, we develop 2 .NET solutions.

Solution 1 contains - amongst others - a couple of .NET Framework 4.7.2 class libraries used in other projects. Some of these class libraries reference the NuGet package System.Text.Json 9.0.11 because this is not natively part of .NET Frakework 4.7.2.

Solution 2 is a ASPNetCore web application targetting .NET 9 . This solution makes use of the class libraries provided by the other solution. Originally, this project also had a version of System.Text.Json installed because it had been upgraded from a .NetCore 3.1 solution using the .NET Upgrade Assistant. However, I recently removed this NuGet package. As far as I'm aware, System.Text.Json is part of the .NET 9 installation anyway, so installing it separately shouldn't be necessary.

Now, for several years we've been having a recurring issue: The web application builds fine, but when the code reaches a specific part, it crashes with the following error message:

System.IO.FileNotFoundException: "Could not load file or assembly 'System.Text.Json, Version=9.0.0.11, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. Das System kann die angegebene Datei nicht finden."

Usually, we were always able to (temporarily) solve this issue by trying around with different combinations of versions of the package installed in both solutions. Then it went well for a while until, after installing some NuGet update, the trouble started anew. This is a real hassle for the one having to deal with it, plus it keeps binding resources every time the issue arises. Needless to say: We would very much like this solved once and for all!

What we are doing:

In Solution 1, we compile the needed class libraries in Release Mode. Then we copy the resulting dlls, the Microsoft dlls referenced by these libraries (Microsoft.Bcl.AsyncInterfaces.dll, System.Buffers.dll, and so on) and the created .dll.config files into the Assemblies directory of Solution 2. Solution 2 references these as external dependencies, Local copy is set to True.

What doesn't work:

As mentioned, compiling Solution 2 works just fine. The issue only occurs at run time. However, I noticed warnings at compile time of class MSB3277 that seem to be related to the problem:

Es wurden Konflikte zwischen verschiedenen Versionen von "System.Text.Json" gefunden, die nicht aufgelöst werden konnten. Konflikt zwischen System.Text.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 und System.Text.Json, Version=9.0.0.11, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51. System.Text.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 wurde aufgrund der primären Eigenschaft System.Text.Json, Version=9.0.0.11, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 vorgezogen. Verweise, die von "System.Text.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" abhängig sind [C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\9.0.11\ref\net9.0\System.Text.Json.dll]. C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\9.0.11\ref\net9.0\System.Text.Json.dll Elementincludes einer Projektdatei, die den Verweis "C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\9.0.11\ref\net9.0\System.Text.Json.dll" verursacht haben. C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\9.0.11\ref/net9.0/System.Text.Json.dll Verweise, die von „System.Text.Json, Version=9.0.0.11, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51“ [] abhängen oder damit vereint wurden. D:\xxx\Assemblies\yyy.dll Elementincludes einer Projektdatei, die den Verweis "D:\xxx\Assemblies\yyy.dll" verursacht haben. zzz

Similar warnings appear for several other packages like System.IO.Pipelines. We've never had issues with these at run time though.

What I think:

I was wondering where Solution 2 got the need to load System.Text.Json version 9.0 from as this version is not explicitly referenced anywhere. When I expand the list of dependencies in the solution explorer, expand Frameworks and then Microsoft.NETCore.App, I can see a reference to System.Text.Json version 9.0. So, to me, this looks like .NET 9 itself is referencing a version of the package that is not up to date. And now this causes version issues with the most recent version of the package I installed from NuGet manager?

We would really appreciate any help in this respect! If how we reference external Assemblies in Solution 2 is not how you're supposed to do it, please feel free to give us a hint about how to improve that.

Answer accepted by question author

1 additional answer

Your answer

Answer 1

Hi,

From your description, changing package versions in both solutions only “works” temporarily because you’re manually shuffling assemblies instead of letting the build system resolve them properly. Manual copying of compiled framework/BCL DLLs causes your net472 libraries to embed a reference the .NET 9 runtime cannot satisfy. Modern .NET does not apply binding redirects to core assemblies as exact assembly version must match.

Key distinction:

NuGet package version 9.0.11 ≠ assembly version 9.0.0.11. Official builds keep the assembly version at 9.0.0.0. So a request for 9.0.0.11 indicates a nonstandard or stale copy was used when compiling.

Verify this first: Inspect a failing library from Solution 1 (replace path):


dotnet tool install --global dotnet-ildasm   # once

dotnet ildasm -t .\Assemblies\YourLibrary.dll | grep System.Text.Json

If you see .ver 9:0:0:11 you must rebuild that library (no fix solely in Solution 2).
If you see .ver 9:0:0:0 then the runtime error is due to a copied/extra System.Text.Json DLL in Solution 2—remove the copy.

Search for stray copies:


find . -name System.Text.Json.dll

Remove any you manually placed in Solution 2.

I suggest this approach:

Multi‑target the libraries in Solution 1 so Solution 2 consumes a native net9.0 build (or netstandard2.0 if you prefer)—not the legacy net472 binary. Only add the System.Text.Json package for targets where it is not inbox (net472 / netstandard2.0). Let .NET 9 use the runtime’s built‑in assembly. Stop copying any System.* / Microsoft.* DLLs between solutions.

This should achieve:

Eliminates the dependency on System.Text.Json, Version=9.0.0.11.
Lets Solution 2 reference a build compiled directly against the .NET 9 reference pack (System.Text.Json assembly version 9.0.0.0).
Removes the need for “version juggling.”
Prevents future NuGet updates from breaking runtime loading.


<Project Sdk="Microsoft.NET.Sdk">

  <TargetFrameworks>net472;netstandard2.0;net9.0</TargetFrameworks>

  <!-- System.Text.Json only where not inbox -->

  <ItemGroup>

    <PackageReference Include="System.Text.Json" Version="9.0.11"

                      Condition="'$(TargetFramework)' != 'net9.0'"

                      PrivateAssets="all" />

  </ItemGroup>

</Project>

Notes:

netstandard2.0 gives broad reuse; keep net472 for existing consumers.
net9.0 build will NOT pull the package; it uses the runtime copy.
PrivateAssets="all" prevents the package from flowing transitively upward unnecessarily.

Web App (Solution 2) Project File


<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>

    <TargetFramework>net9.0</TargetFramework>

    <Nullable>enable</Nullable>

    <ImplicitUsings>enable</ImplicitUsings>

  </PropertyGroup>

  <ItemGroup>

    <ProjectReference Include="..\\Solution1\\YourSharedLibrary.csproj" />

  </ItemGroup>

</Project>

Migration Steps

Update each Solution 1 library to multi‑target as shown.
Remove the “Assemblies” folder copies of System.*, Microsoft.*, System.Text.Json.dll from Solution 2 (keep only proprietary company DLLs until they’re also multi‑targeted).
Replace file <Reference> entries in Solution 2 with <ProjectReference>.
Delete all bin and obj folders (both solutions).
Rebuild.

uds 25 Reputation points

2025-11-17T07:50:40.9866667+00:00

Thank you for your quick answer and thorough explanations!

To clarify:

All references in Solution 2 to our libraries from Solution 1 get replaced by project references. I didn't know this was possible between separate solutions. When that is done we get rid of the complete Assemblies folder in Solution 2 as we only provide our own libraries (+ dependencies) there which won't be necessary any longer.

To achieve this, we first have to multi-target the needed libraries from Solution 1 so they use native .NET dependencies for compilation when pulled in by Solution 2. This means that, in the end, we won't have to take any extra steps anymore when code changes happened in Solution 1 because with every compilation of Solution 2 the necessary libraries get pulled in automatically. I suppose it doesn't make any difference that some of the needed libraries from Solution 1 are written in C# and some are in VB.Net. I'll just create a project reference to the respective project file.

I suppose we would multi-target Solution 1 for .NET Framework 4.7.2 and .NET 9.0. As far as I got it, that should be a possible way to go. Right now, I don't see why I should also target it for .NET Standard 2.0.

As far as I can see it, this sounds like a pretty clean solution! We'll have to check if there are any project paths differing on separate computers (which would make finding suitable relative paths for the project references more difficult). I'll get back to you as soon as I tried this.
Danny Nguyen (WICLOUD CORPORATION) 5,065 Reputation points Microsoft External Staff Moderator

2025-11-17T10:33:20.3066667+00:00

That's great, let me know if you need any help.
uds 25 Reputation points

2025-11-17T11:22:14.51+00:00

It looks like the project files of our library projects in Solution 1 are still in legacy style, not in SDK style. Is there an easy way to upgrade this without breaking anything? All I found so far looked pretty time consuming and required lots of manual work...

[EDIT:]

I was able to convert the first project file using the .NET Upgrade Assistant. Which is deprecated. For the record: Not everybody wants to be forced to use Copilot, Microsoft.

However, with a couple of additional manual changes, I was able to multi-target the first project. Now, when I try to add a project reference to Solution 2, the build process fails saying that project information for xxx.vbproj could not be found and that the project was possibly not loaded. This post suggests you can't reference projects that are not part of the same solution.

So, will I have to add all needed library projects to Solution 2? Or am I doing something wrong?
Danny Nguyen (WICLOUD CORPORATION) 5,065 Reputation points Microsoft External Staff Moderator

2025-11-18T02:48:32.5266667+00:00

You should put both solutions under an umbrella solution containing:

The web app (solution 2)

library projects (solution 1, SDK style, multi-targeted)
uds 25 Reputation points

2025-11-18T15:36:16.2533333+00:00

Ah, okay, thank you.

Wouldn't it be easier to directly include the library projects in Solution 2? That way, we could develop them in Solution 1 like we're doing now and let them be pulled into Solution 2 at compile time. If I create a third solution containing both parts, I won't be able to properly develop Solution 2 anymore because there will be dependencies missing, right? Or am I missing something here?

[EDIT:]

I ended up simply adding the needed libraries from Solution 1 to Solution 2. I had to manually edit a couple of lines in the project files, but everything seems to be working now!

Only issue remaining is inconsistencies in how our devs named Solution 1's root folder. So, right now we'd have to adjust the relative paths to referenced projects in Solution 2 for some of the devs. This is a bummer. But we'll solve that one way or another.

Also, we'll have to edit a couple of files when we change Solution 2's target framework. Still, to my mind, this is a pretty clean solution.

Thank you for your help and explanations!

Answer 2

It sounds like you're facing a classic issue with versioning and assembly references in .NET, particularly with the System.Text.Json library across different solutions targeting different frameworks. Here are some steps and considerations that might help you resolve the issue:

Binding Redirects: Since you are dealing with multiple versions of System.Text.Json, you might need to add binding redirects in your app.config or web.config file in Solution 2. This will instruct the runtime to redirect requests for one version of the assembly to another version. For example:

   <configuration>
     <runtime>
       <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <dependentAssembly>
           <assemblyIdentity name="System.Text.Json" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
           <bindingRedirect oldVersion="0.0.0.0-9.0.0.11" newVersion="9.0.0.11" />
         </dependentAssembly>
       </assemblyBinding>
     </runtime>
   </configuration>

This will help ensure that the correct version is loaded at runtime.

NuGet Package Management: Ensure that both solutions are using compatible versions of the System.Text.Json package. Since Solution 1 uses version 9.0.11, you should ensure that Solution 2 references the same version explicitly, even if it is included in .NET 9. This can help avoid conflicts.
Clean and Rebuild: After making changes to your references or configuration files, perform a clean and rebuild of both solutions. This ensures that any cached versions of assemblies are cleared out and that the latest versions are used.
Check for Transitive Dependencies: Sometimes, other NuGet packages may have dependencies on specific versions of System.Text.Json. Use the NuGet Package Manager to inspect the dependency tree and ensure that there are no conflicting versions being pulled in.
Review Assembly References: In Solution 2, ensure that you are not inadvertently referencing older versions of the assemblies. Check the references in your project file (.csproj) and ensure that they point to the correct versions.
Use Local Copies Wisely: While copying the DLLs to the Assemblies directory can work, it can also lead to confusion if versions are mismatched. Consider using NuGet to manage dependencies instead of manually copying DLLs, as this will help maintain consistency across projects.
Runtime Configuration: If you are still encountering issues, consider using the Microsoft.Extensions.DependencyModel to inspect the runtime dependencies and ensure that the correct versions are being resolved at runtime.

By following these steps, you should be able to mitigate the versioning issues with System.Text.Json and ensure that your applications run smoothly without runtime exceptions related to assembly loading.

References:

Share via

Mismatching versions of System.Text.Json

1 additional answer

Your answer