如何修复错误“无法加载文件或程序集‘System.Text.Json，...”？

Question

• I created in VS Code a new classlib project.
• I added two packages to my project: PowerShellStandard.Library + System.Text.Json .

My csproj file contains this block:

  <ItemGroup>
    <PackageReference Include="PowerShellStandard.Library" Version="5.1.1" />
    <PackageReference Include="System.Text.Json" Version="4.7.0" />
  </ItemGroup>

My .cs file uses System.Text.Json and System.Management.Automation .

It does not throw me any error/warning in VS Code when I use JsonSerializer.Serialize(...) . It also compiles without errors or warning when running do.net build . I can import it but, finally, when I run the code I receive the following error:

Get-JsonString : Could not load file or assembly 'System.Text.Json, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
At line:1 char:1
+ Get-JsonString -input s
+ ~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Get-JsonString], FileNotFoundException
+ FullyQualifiedErrorId : System.IO.FileNotFoundException,UrlCSharpPowerShell.CreateJson

What am I missing here?

Answer 1

I had this issue because I had a dependency on Microsoft.Extensions.Configuration.Json in project B that targeted netstandard. Microsoft.Extensions.Configuration.Json requires System.Text.Json when starting .NETStandard, but not dotnetcore.

My problem came when in project A that targeted dotnetcore3.1 referenced project B. At runtime, AWS Lambda was still expecting System.Text.Json to be there.

To resolve the issue, I ended up switching project B to target dotnetcore3.1 as well, even though it is a pure library and not something executable.

Not sure this answers your question directly as I don't fully understand your situation, but a possible solution for this scenario. It was a little difficult finding many other resources on this issue but I probably just don't know what to look for.

Answer 2

I had this issue recently with the following message: "Could not load file or assembly 'System.Text.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51". I had updated the nuget packages of the System.Text.Json (6.0.2) and IdentityModel (6.0.0) as part of a nuget update operation across the projects.

The culprit was the this latest version of System.Text.Json (6.0.2) which was not compatible as a dependency for IdentityModel package latest version (6.0.0), which requires System.Text.Json, Version=6.0.0.0.

Uninstalled the IdentityModel and reinstalled it, and the problem was fixed.

Answer 3

I got the same exact error stating that it could not find system.text.json assembly version 7.0.0.

After wasting half a day I realized that I had recently update a bunge of dependencies, and that.Net 7 was also released only a 2 weeks ago. So I had updated a dependency that used system.text.json to a .NET 7 version by accident.

Solution for me was updating Visual Studio to the latest version that came with .NET 7 SDK and updating the project target framework to .NET 7

Answer 4

Just install the nuget package for the System.Text.Json with the version number that it is complaining about.

Answer 5

只需将 Nuget 包或 System.Text.Json 更新到 4.7.2 及更高版本。

Answer 6

These changes in.csproj file helped me (everything else didn't)

Answer 7

I spent two days on this and it seems that you are facing a dll hell basically in my case I used a plugin which attached to the main application
and internally it uses one of the packages that depends on System.Text.Json

the exception was

Could not load file or assembly 'System.Text.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.

which doesn't really help but seeing the fusionLog indicates that the package IdentityModel was depending on System.Text.Json so when checked the dlls was correctly there

So i have to use Process Explorer which helped me to understand which and assembly was loaded and here's the surprise we have dll hell which means my application loaded different assembly of same dll but with older version

so the solution was to downgrade the plugin to the same package that was used by the main process