Skip to content

System.Text.Json dependency is broken for net6.0 when used in netstandard2.0 library #2033

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nesc58 opened this issue Mar 21, 2023 · 5 comments
Labels

Comments

@nesc58
Copy link

nesc58 commented Mar 21, 2023

Describe the bug
Conflict between System.Text.Json Version 6.0.0 and Version 7.0.0

System.IO.FileNotFoundException: Could not load file or assembly 'System.Text.Json, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. 
File name: 'System.Text.Json, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

When RestSharp is installed in a netstandard2.0 library project System.Text.Json will be used with version 7.0.2 in this library, because RestSharp installs System.Text.Json version 7.0.2 for netstandard2.0.
When this library is used in a net6.0 console app the errors occurs because net6.0 uses System.Text.Json in version 6.0.0 internally and System.Text.Json 7.0.2 is not installed explicit.

To Reproduce

  1. Create a Library project with netstandard2.0
  2. Install RestSharp
  3. Create a wrapper class for RestSharp with custom SystemTextJsonSerializer (see WrappedClient example)
  4. Create a console app with .net6.0
  5. Add the library project to the console app
  6. Call the constructor of the wrapped client

Wrapped Client

using System.Text.Json;
using System.Text.Json.Serialization;
using RestSharp;
using RestSharp.Serializers.Json;

namespace LibraryA;

public sealed class WrappedClient
{
    private static readonly JsonSerializerOptions SerializerOptions = new()
    {
        Converters =
        {
            new JsonStringEnumConverter()
        },
        PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
        PropertyNameCaseInsensitive = true,
        DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull
    };

    private readonly RestClient _client;

    public Client()
    {
        _client = new RestClient(new RestClientOptions(), configureSerialization: sc => sc.UseSerializer(() => new SystemTextJsonSerializer(SerializerOptions)));
    }
}

Console App

try
{
    var client = new LibraryA.WrappedClient();
    Console.WriteLine("Client created");
}
catch (Exception e)
{
    Console.WriteLine("Client creation failed");
    Console.WriteLine(e);
    throw;
}

Possible Solutiosn
I have no idea if this problem is RestSharp related. I have no idea what's the correct solution for RestSharp to fix this.
The actual dependencies are broken when a library (netstandard2.0) installs RestSharp and uses System.Text.Json e.g. to configure the serializer and the library is used in a net6.0 application.
My first thoughts are that RestSharp must fix this because RestSharp is installing the dependencies. But I have found a solution for me (see below).

So the question is: Should RestSharp fix the dependencies so it can easily be used in libraries? For example a possible solution could be installing System.Text.Json for all frameworks in Version 7.0.2. Another solution could be to install a lower version of System.Text.Json for netstandard2.0 which fits to the frameworks. I have really no idea.

Workaround / my solution for now:
The first possible workaround is installing System.Text.Json in version 7.0.2 explicit in the library project.
Another solution is to build the library project with <TargetFrameworks>netstandard2.0;net6.0</TargetFrameworks>. So the correct version of System.Text.Json will be used for net6.0

@nesc58 nesc58 added the bug label Mar 21, 2023
@alexeyzimarev
Copy link
Member

Could you elaborate how RestSharp is installed as a .NET Standard library to a .NET 6 project? RestSharp builds for .NET 6 and .NET 7 as native targets. It also only references System.Text.Json package for .NET Standard and .NET Framework.

    <ItemGroup Condition="$(TargetFramework) != 'net6.0' And $(TargetFramework) != 'net7.0'">
        <PackageReference Include="System.Text.Json" Version="7.0.2" />
    </ItemGroup>

@alexeyzimarev
Copy link
Member

image

@nesc58
Copy link
Author

nesc58 commented Mar 21, 2023

I have created an example project: https://github.com/nesc58/RestSharpBrokenDependencies

Compiling the TestProjectA which reference LibraryA using netstandard2.0 will result in compile warnings (Conflict between System.Text.Json 7.0.0 and System.Text.Json 6.0.0.0)

Compling and running TestProjectB which reference LibraryB using netstandard2.0;net6.0;net7.0 will not cause in these errors.

I think the dependencies are resolved as following:
LibraryA resolves RestSharp System.Text.Json with Version 7.0.2 (as seen on your screenshot - using netstandard2.0)
TestProjectA resolves RestSharp not referencing System.Text.Json (net6.0 does not require explicit System.Text.Json reference). The LibraryA uses System.Text.Json to create the settings. I think this is the point where the dependencies got broken because LibraryA uses System.Text.Json 7.0.2 which can not be resolved by TestProjectA because the implicit reference is System.Text.Json 6.0.0

Maybe my fault is is creating a library with only targeting netstandard2.0. LibraryB and TestProjectB are running as expected.

Moving the usage of System.Text.Json out of the library and passing the IRestSerializer with constructor injection everything works fine. (LibraryC / TestProjectC)

Any thoughts or hints? I will solve the problem using the way of LibraryB

@alexeyzimarev
Copy link
Member

I think the only way to fix it is to remove the referenced package condition and make all the targets depend on System.Text.Json 7.0.2, so it will be installed.

@alexeyzimarev
Copy link
Member

Of course the workaround is to install the System.Text.Json package 7.0.2 or higher to the project that references LibraryA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants