Severity: Info / Code Quality

Files:

• src/Servy.Core/Services/ServiceExporter.cs lines 69-76 and 84-102
• src/Servy.Core/Services/JsonServiceSerializer.cs lines 44-60

Finding

The codebase has two parallel JSON-export paths for the same ServiceDto, and they configure Newtonsoft.Json differently, so the output for the same DTO is not byte-for-byte identical.

ServiceExporter.ExportJson(ServiceDto service):

return JsonConvert.SerializeObject(service, Newtonsoft.Json.Formatting.Indented,
    new JsonSerializerSettings
    {
        NullValueHandling = NullValueHandling.Ignore
    });

JsonServiceSerializer.Serialize(ServiceDto? dto):

return JsonConvert.SerializeObject(dto, Formatting.Indented, JsonSecurity.UntrustedDataSettings);

JsonSecurity.UntrustedDataSettings (src/Servy.Core/Security/JsonSecurity.cs):

public static readonly JsonSerializerSettings UntrustedDataSettings = new JsonSerializerSettings
{
    TypeNameHandling = TypeNameHandling.None,
    MaxDepth = 32,
    MetadataPropertyHandling = MetadataPropertyHandling.Ignore
};

The two settings objects do not overlap:

• ServiceExporter omits null-valued properties (NullValueHandling.Ignore) — produces a smaller JSON file with only set fields.
• JsonServiceSerializer emits all null-valued properties — produces a larger JSON file with explicit null everywhere.

Both paths are reachable from ServiceCommands (Servy and Servy.Manager) and from the CLI, so the same export operation can produce different files depending on which code path is used.

Why this matters

• Round-trip drift between exporter and serializer: a config exported by ServiceExporter.ExportJson will look different from one produced by JsonServiceSerializer.Serialize, even when the source DTO is byte-identical.
• The two implementations are also asymmetric with the parallel issue tracked in [Code Quality] ServiceRepository.ExportXmlAsync — bypasses injected IXmlServiceSerializer, asymmetric with ImportXmlAsync (parallel to #822) #968 (XML side) and [Code Quality] ServiceCommands.ImportXmlConfigAsync/ImportJsonConfigAsync — instantiates serializers directly instead of using validators-style DI #832 (direct-instantiation pattern) — the desktop apps call the static ServiceExporter, while the repository wires up the injected IJsonServiceSerializer.
• A single user-visible setting (e.g. enabling/disabling "omit nulls") is impossible to centralize while there are two divergent serializer configurations.

Suggested fix

• Pick one canonical settings object (probably extending JsonSecurity.UntrustedDataSettings to add NullValueHandling = NullValueHandling.Ignore).
• Have JsonServiceSerializer.Serialize and ServiceExporter.ExportJson share that single object.
• Long-term: collapse ServiceExporter into IJsonServiceSerializer / IXmlServiceSerializer so there is only one export path (matches the direction implied by [Code Quality] ServiceRepository.ExportXmlAsync — bypasses injected IXmlServiceSerializer, asymmetric with ImportXmlAsync (parallel to #822) #968 and [Code Quality] ServiceCommands.ImportXmlConfigAsync/ImportJsonConfigAsync — instantiates serializers directly instead of using validators-style DI #832).