Overview
This repository packages Codebelt's YAML extensions as a layered set of libraries instead of a single all-or-nothing integration. At the center is a formatter pipeline over YamlDotNet, and the surrounding packages adapt that pipeline to ASP.NET Core fault responses, MVC request and response formatting, or a single aggregate package reference.
Concepts
The packages line up by boundary: formatter core first, then web-host integration, then packaging shortcuts for applications that want the whole stack.
Formatter-centric YAML configuration
Codebelt.Extensions.YamlDotNet treats YAML work as a formatter problem instead of a loose collection of serializer helpers. YamlFormatter, YamlFormatterOptions, and YamlSerializerOptions keep naming, recursion, media-type, sensitivity, and converter registration in one pipeline, while YamlConverterFactory and YamlConverter<T> let callers add formatter-aware conversion logic without dropping down to raw YamlDotNet builder code.
That matters beyond ordinary object serialization. The same package-owned pipeline is used for multi-document parsing and for exception-oriented payloads such as ExceptionDescriptor, so applications can keep diagnostic YAML output aligned with the rest of their serializer settings instead of maintaining a separate failure serializer.
Fault payloads at the ASP.NET Core boundary
Codebelt.Extensions.AspNetCore.Text.Yaml moves the core formatter model into ASP.NET Core service registration. Its converter extensions for ProblemDetails, IDecorator<ProblemDetails>, and HttpExceptionDescriptor, together with AddYamlFormatterOptions, AddYamlExceptionResponseFormatter, and AddMinimalYamlOptions, define the repository's HTTP fault-response boundary.
The important distinction is that this package does not introduce MVC request and response body formatters. It focuses on YAML exception-response behavior and the DI registrations needed to keep YamlFormatterOptions authoritative for media types and sensitivity settings inside an ASP.NET Core application.
MVC content negotiation over the same YAML pipeline
Codebelt.Extensions.AspNetCore.Mvc.Formatters.Text.Yaml extends the ASP.NET Core layer into full MVC content negotiation. AddYamlFormatters, AddYamlFormattersOptions, YamlSerializationMvcOptionsSetup, YamlSerializationInputFormatter, and YamlSerializationOutputFormatter attach YAML input and output handling to MvcOptions, while still reusing the lower-level option and exception-response services from Codebelt.Extensions.AspNetCore.Text.Yaml.
This separation keeps the web boundary explicit. Applications that only need YAML fault payloads can stop at the ASP.NET Core package, while controller-based APIs that need YAML request bodies and negotiated responses can add the MVC formatter package without replacing the underlying formatter model from Codebelt.Extensions.YamlDotNet.
Aggregate packaging without new APIs
Codebelt.Extensions.YamlDotNet.App is a packaging concept rather than an API surface. Its project references show that it brings in Codebelt.Extensions.YamlDotNet, Codebelt.Extensions.AspNetCore.Text.Yaml, and Codebelt.Extensions.AspNetCore.Mvc.Formatters.Text.Yaml, but the consumer-facing types still live in those referenced packages.
That makes the aggregate package a deployment shortcut, not a new programming model. It is useful when an application wants the entire YAML stack through one package reference, but it should not obscure which package owns the formatter APIs, the ASP.NET Core service registrations, or the MVC formatter types.
Usage guidance
Choose the smallest package that matches the boundary you actually need. Start with Codebelt.Extensions.YamlDotNet for formatter-centric serialization, parsing, and diagnostic YAML output. Add Codebelt.Extensions.AspNetCore.Text.Yaml when the application needs YAML fault responses in ASP.NET Core, and add Codebelt.Extensions.AspNetCore.Mvc.Formatters.Text.Yaml only when MVC endpoints should negotiate YAML request or response bodies.
Use Codebelt.Extensions.YamlDotNet.App only when the application genuinely wants the full stack through one reference. Installing the aggregate package for a serializer-only or fault-response-only scenario adds layers that the smaller packages already expose directly.