Configurable JSON serialization support (Newtonsoft.Json vs System.Text.Json)

[serber]

WireMock.Net forces me to use Newtonsoft.Json as the only serialization option. In modern .NET applications that have migrated to System.Text.Json, this creates dependency conflicts, performance overhead, and inconsistent serialization behavior between production code and test mocks. When my application uses System.Text.Json with specific naming policies and converters, WireMock's Newtonsoft.Json serialization can produce different results, leading to unreliable tests that don't accurately reflect production behavior.

I would like WireMock.Net to support configurable JSON serialization, allowing users to choose between Newtonsoft.Json (current default) and System.Text.Json. This could be implemented through:

// Configuration option
WireMockServer.Start(new WireMockServerSettings
{
    JsonSerializer = JsonSerializerType.SystemTextJson
});

// Or fluent API
var server = WireMockServer
    .Start()
    .UseSystemTextJson()
    .WithSettings(settings);

Additional context

• System.Text.Json offers significantly better performance (up to 2x faster serialization)
• Many .NET 5+ projects have migrated away from Newtonsoft.Json
• Microsoft recommends System.Text.Json for new applications
• This feature would help WireMock.Net stay current with .NET ecosystem trends
• Backward compatibility can be maintained by keeping Newtonsoft.Json as the default option
• Would be valuable for high-throughput testing scenarios where serialization performance matters

[StefH]

@serber
Note that it's already possible to provide the json serializer here:
https://github.com/wiremock/WireMock.Net/blob/master/src/WireMock.Net.Minimal/ResponseBuilders/Response.WithBody.cs#L217

Or do you mean something else?

[molander-dev]

@serber Note that it's already possible to provide the json serializer here: https://github.com/wiremock/WireMock.Net/blob/master/src/WireMock.Net.Minimal/ResponseBuilders/Response.WithBody.cs#L217

Or do you mean something else?

Yeah its not about the serializer used in wiremock, its that wiremock globally sets Newtonsoft for the project you install Wiremock.NET to. So if our project uses System.Text and we install the Wiremock.NET package it breaks all our code that uses the System.Text.Json.JsonSerializer

[StefH]

Normally you would install WireMock.Net in a unit test project.
And I do not understand how adding WireMock.Net breaks / changes the json serializer used.

Can you please provide a complete example?

[molander-dev]

Normally you would install WireMock.Net in a unit test project. And I do not understand how adding WireMock.Net breaks / changes the json serializer used.

Can you please provide a complete example?

Yes here's an example.

Before installing WireMock.NET package to my NUnit test project I have this helper class.

public class DateTimeHelper : JsonConverterFactory
{
   public override bool CanConvert(Type typeToConvert)
   {
      return typeToConvert == typeof(DateTime) || typeToConvert == typeof(DateTime?);
   }

   public override JsonConverter CreateConverter(Type typeToConvert, JsonSerializerOptions options)
   {
      if (typeToConvert == typeof(DateTime))
      {
         return new DateTimeConverter();
      }
      else if (typeToConvert == typeof(DateTime?))
      {
         return new NullableDateTimeConverter();
      }

      throw new InvalidOperationException($"Cannot create converter for {typeToConvert}");
   }

   public static string? GetDateAsString(DateTime? dateTime) => dateTime?.ToString("yyyy-MM-ddTHH:mm:ss", CultureInfo.InvariantCulture);
}

After installing the Wiremock.NET to the project this method breaks and this part will say JsonConverter is a namespace but is used as a type.

public override JsonConverter CreateConverter(Type typeToConvert)

So then we need to add a custom using to keep using system.text

using STJsonConverter = System.Text.Json.Serialization.JsonConverter;

public override STJsonConverter CreateConverter(Type typeToConvert, JsonSerializerOptions options)

[tavisca-mjadhav]

Hello @StefH

Yes I agree with @serber . Even I have a scenario where Newtonsoft.Json actually breaking during the HTTP recording phase.
In my case the my .net application is using the System.Text.Json serializer in all cases. In one of the use case, my application is making 3rd part call over the HTTPS network sending & receiving JSON data. This call is authenticated, as part of "SHA" body hash authentication mechanism, & the application computes the HASH value of the body by converting the request using System.Text.Json serializer to string. This SHA value is passed via header.

Now when I use proxy recording feature of the wiremock, to perform the recording of the outgoing call, Wiremock internally tries to parse the outgoing http request payload as JSON using newtonsoft JSON, and then it forwarded to actually 3'rd party service.
At this moment i receive unauthorized error. This is because of the difference in Hash value when HASH is computed via System.Text.Json and Newtonsoft.Json string serialization. There is different behavior used by System.Text.Json when it comes to serialize the special characters & encoding as compared to NewtonSoft.Json.

system-text-json/character-encoding .

• By default System.text.Json escape HTML-sensitive characters such as <, >, &, and '.
• Newtonsoft.Json, by default, does not escape HTML-sensitive characters such as <, >, &, and ' during serialization in the same way that System.Text.Json does for defense-in-depth against XSS or information-disclosure attacks.

Due to this difference in behavior, the HASH value computed before sending the call over the network & after receiving over the network for verification by the 3'rd party service is different (Though body has the same Json value).

So allowing Wiremock to choose between desired serializer will be of more helpful.

[StefH]

@tavisca-mjadhav
Did you try this?

It's already possible to provide the json serializer here:
https://github.com/wiremock/WireMock.Net/blob/master/src/WireMock.Net.Minimal/ResponseBuilders/Response.WithBody.cs#L217