runtime: Referencing `System.Text.Json` fails compilation with CS1705 (ERR_AssemblyMatchBadVersion)
Description
Build started...
1>------ Build started: Project: ClassLibrary1, Configuration: Debug Any CPU ------
1>C:\Program Files\dotnet\sdk\8.0.100-preview.1.23115.2\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(287,5): message NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
1>CSC : error CS1705: Assembly 'System.Text.Json' with identity 'System.Text.Json, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' uses 'System.Memory, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' which has a higher version than referenced assembly 'System.Memory' with identity 'System.Memory, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
1>Done building project "ClassLibrary1.csproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
========== Build started at 10:08 AM and took 00.384 seconds ==========
Reproduction Steps
csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.Text.Json" Version="7.0.2" />
</ItemGroup>
</Project>
cs:
using System.Text.Json.Nodes;
namespace ClassLibrary1
{
public class Class1
{
private object _x = JsonNode.Parse(string.Empty);
}
}
Expected behavior
No error
Actual behavior
error CS1705: Assembly ‘System.Text.Json’ with identity ‘System.Text.Json, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’ uses ‘System.Memory, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’ which has a higher version than referenced assembly ‘System.Memory’ with identity ‘System.Memory, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’
Regression?
Yes. Referencing 6.0.7 version of the package works. Likely regressed by https://github.com/dotnet/runtime/pull/73871
Known Workarounds
No response
Configuration
No response
Other information
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 18 (18 by maintainers)
The NuGet package cache is writeable by the build, so bad behaved builds can do this. If you hit it again, an interesting datapoint would be to crack open that package to see if it is busted too. If the package has the wrong file then the problem is up-stream on some feed you’re pulling the package from. If the package is correct - then something on your machine modified the package cache.
I’ve seen someone using hardlinks + a non-standard copy (open + write rather than OS copy API) accidentally modify their package cache before.
@Youssef1313 excellent, I can reproduce locally