Overview
This repository packages a layered Newtonsoft.Json stack for applications that need more than ad hoc JsonSerializerSettings changes. At the base, it adds formatter, converter, contract-resolver, and JSON traversal APIs; higher layers project those same conventions into ASP.NET Core fault responses and MVC body formatting. The result is a set of packages that can share one serialization model across library code, service registration, and controller pipelines.
Concepts
The packages in this repository are easiest to understand as layers around one formatter model. Start with the core JSON primitives, then add the ASP.NET Core or MVC integration layers only when the host actually needs them.
Shared formatter conventions
Codebelt.Extensions.Newtonsoft.Json defines the core serialization model for the repository. NewtonsoftJsonFormatter, NewtonsoftJsonFormatterOptions, JsonConverterCollectionExtensions, DynamicContractResolver, and the JData APIs let a caller standardize naming strategy, converter registration, stream-based formatting, and JSON traversal without building those pieces separately around raw Json.NET.
That core layer matters because the higher packages do not introduce a separate JSON abstraction. They reuse the same formatter options and converter model, so serializer behavior can stay aligned whether the code is running inside a library workflow, an ASP.NET Core fault formatter, or MVC request and response handling.
Fault payload serialization in ASP.NET Core
Codebelt.Extensions.AspNetCore.Newtonsoft.Json turns the shared formatter model into ASP.NET Core registrations for exception and problem response payloads. Its service collection extensions register HttpExceptionDescriptorResponseFormatter<NewtonsoftJsonFormatterOptions> and extend the converter set for ProblemDetails, HttpExceptionDescriptor, and StringValues, which keeps ASP.NET Core fault serialization on the same settings and sensitivity rules as the core formatter.
This is the package boundary for host-level error response formatting. If an application needs DI-managed fault output but does not need MVC body formatters, this layer is the direct fit.
MVC formatter precedence
Codebelt.Extensions.AspNetCore.Mvc.Formatters.Newtonsoft.Json applies the same formatter conventions to MVC controller input and output. JsonSerializationMvcOptionsSetup inserts JsonSerializationInputFormatter and JsonSerializationOutputFormatter at the front of MvcOptions, so controller body handling prefers the repository's Newtonsoft-based formatter pipeline over later MVC formatters.
This layer builds on the ASP.NET Core formatter package instead of bypassing it. The MVC builder extensions delegate option registration to the ASP.NET Core registrations, which keeps controller body formatting and JSON exception response formatting tied to the same NewtonsoftJsonFormatterOptions instance.
Bundle versus focused references
Codebelt.Extensions.Newtonsoft.Json.App is a packaging shortcut, not another API layer. Its project disables build output and references the three implementation packages so an application can install the full stack with one package reference.
That bundle is useful when one application needs the full layering described above, but it is intentionally broader than the focused packages. The repository is designed so a library or service can stop at the smallest package that matches its host and serialization responsibilities.
Usage guidance
Start with Codebelt.Extensions.Newtonsoft.Json when the job is serializer settings, converter registration, or JSON document inspection inside application or library code. Add Codebelt.Extensions.AspNetCore.Newtonsoft.Json when the host needs DI-managed fault response formatting, and add Codebelt.Extensions.AspNetCore.Mvc.Formatters.Newtonsoft.Json only when MVC request and response bodies should run through the same Newtonsoft pipeline.
Choose Codebelt.Extensions.Newtonsoft.Json.App only when one application genuinely needs all three layers. If a project only needs lower-level JSON helpers or only ASP.NET Core fault formatting, the smaller package keeps the dependency graph closer to the actual host boundary.