Cuemon for .NET

Overview

Cuemon for .NET is a layered utility ecosystem for .NET applications that want reusable infrastructure code without hiding the underlying platform APIs. The repository starts with low-level contracts for validation, configuration, conversion, disposal, and decoration, then grows outward into data access, integrity, serialization, networking, caching, resilience, and ASP.NET Core integration. You can adopt a narrow package for one boundary or step up into broader adapter layers and curated aggregate packages when a solution intentionally needs that wider surface.

Concepts

The repository is easiest to understand as stacked capability layers. Lower packages define reusable contracts and algorithms, middle packages adapt those pieces to familiar BCL and hosting workflows, and upper packages plug the same models into HTTP, MVC, Razor Pages, JSON, and XML application boundaries.

Foundations stay explicit and extension-first

Cuemon.Kernel is the lowest layer: guards, option-object conventions, decorators, byte-order-mark handling, disposal contracts, and retry-until-success helpers. Cuemon.Core builds on that base with parsing, formatting, hash abstractions, date and range models, reflection-friendly factories, region data, and paging or partitioning types. The extension-oriented layer on top keeps those primitives close to standard .NET surfaces instead of inventing a replacement framework: Cuemon.Extensions.Core adds wrappers, conversions, and hierarchy traversal; Cuemon.Extensions.Collections.Generic and Cuemon.Extensions.Collections.Specialized add pagination, partitioning, and collection-shape bridges; Cuemon.Extensions.Reflection turns common inheritance and metadata traversal into direct reflection helpers; Cuemon.Extensions.DependencyInjection adds forwarded service registration and idempotent options configuration; and Cuemon.Extensions.Hosting keeps environment-aware configuration-source mutation in the host bootstrap path.

Data, integrity, and cache validation share one model

Cuemon.Data treats relational, DSV, and XML-shaped inputs through one IDataReader-style model, with DataStatement, provider-facing execution shells, query builders, and row materialization helpers. Cuemon.Data.SqlClient is the SQL Server specialization of that model, while Cuemon.Extensions.Data keeps reader materialization, DbType mapping, and query-fragment shaping attached to familiar ADO.NET types. Alongside that data surface, Cuemon.Data.Integrity defines CacheValidator, checksum builders, and file or assembly-derived freshness models, and Cuemon.Extensions.Data.Integrity turns those integrity objects into extension-driven workflows. That shared integrity model matters outside storage too: the same checksum and timestamp concepts later reappear in HTTP caching through Cuemon.AspNetCore.Mvc, Cuemon.Extensions.AspNetCore, and Cuemon.Extensions.AspNetCore.Mvc.

Serialization stays formatter-driven across streams, text, JSON, and XML

Cuemon.IO and Cuemon.Extensions.IO cover the stream boundary: in-memory stream creation, encoding-aware conversion, concatenation, and compression. Text helpers stay intentionally thin: Cuemon.Extensions.Text exposes BOM-aware encoding detection and fail-fast string conversion without forcing decorator plumbing into consumer code. JSON and XML then build on the same formatter idea instead of on one-off serializer wrappers. Cuemon.Extensions.Text.Json extends System.Text.Json with a Cuemon-aware formatter pipeline and converter registration for faults and framework-adjacent types, while Cuemon.Xml provides a converter-driven XML serializer with pluggable XmlConverter implementations, stream factories, and reader or writer helpers. Cuemon.Extensions.Xml is the ergonomic XML layer for chunking, copying, sanitizing, and converter registration around that serializer model.

HTTP and ASP.NET Core layers build upward from reusable primitives

Cuemon.AspNetCore defines the reusable HTTP and middleware foundation: configurable middleware base classes, typed HTTP exceptions, server-timing support, correlation and request identifiers, fault descriptors, throttling, and cache-busting tokens. Cuemon.Extensions.AspNetCore is the host adapter that turns those primitives into service registrations, middleware wiring, conditional-request helpers, and in-memory throttling cache setup. Authentication follows the same pattern: Cuemon.AspNetCore.Authentication owns the Basic, Digest, and HMAC flows, while Cuemon.Extensions.AspNetCore.Authentication plugs them into AuthenticationBuilder, direct middleware registration, and negotiated authorization-failure responses.

On top of that request-pipeline layer, Cuemon.AspNetCore.Mvc and Cuemon.Extensions.AspNetCore.Mvc translate cache validators, fault mapping, throttling, and server timing into MVC results, filters, and builder extensions. Cuemon.AspNetCore.Razor.TagHelpers and Cuemon.Extensions.AspNetCore.Mvc.RazorPages keep asset URL composition and optional cache busting aligned between Razor markup and page-model code. Serializer adapters stay layered as well: Cuemon.Extensions.AspNetCore.Text.Json and Cuemon.Extensions.AspNetCore.Xml make ASP.NET Core-specific types flow through the Cuemon formatter pipelines, while Cuemon.Extensions.AspNetCore.Mvc.Formatters.Text.Json and Cuemon.Extensions.AspNetCore.Mvc.Formatters.Xml move those formatter options directly into MVC negotiation. If you want that whole web-facing surface from one reference, Cuemon.AspNetCore.App is the curated aggregate package for the ASP.NET Core stack.

Runtime behavior is packaged as explicit boundaries

Cuemon.Diagnostics measures synchronous and asynchronous delegates with structured timing metadata and also maps exceptions into descriptor objects. Cuemon.Extensions.Diagnostics is a small bridge that promotes file-version metadata into the same typed diagnostics model. Cuemon.Resilience adds explicit transient retry loops, latency ceilings, and retry callbacks around delegates rather than around a policy registry. Caching follows the same explicit style: Cuemon.Runtime.Caching provides the small cache contract and SlimMemoryCache, while Cuemon.Extensions.Runtime.Caching adds read-through caching and delegate memoization on top. Concurrency and await policy are likewise separated by layer: Cuemon.Threading provides result-ordered parallel loop primitives, and Cuemon.Extensions.Threading gives Task continuations named intent instead of raw ConfigureAwait flags.

Networking and trust stay at the boundary where they matter

Cuemon.Net provides the lower-level networking boundary: HttpManager, query-string models, remote change watchers, and batched SMTP delivery. Cuemon.Extensions.Net keeps those flows attached to Uri and adds signed-URI helpers plus lightweight HttpClient factory management for managed outbound HTTP reuse. Cuemon.Security.Cryptography supplies the cryptographic side of that trust boundary through keyed and unkeyed hash factories, HMAC helpers, AES encryption, and SHA-512/256 support. Together with the HMAC and Digest pieces in Cuemon.AspNetCore.Authentication, these packages make trust decisions explicit at the edge: signing payloads, verifying URLs, hashing artifacts, and authenticating requests are all represented as first-class APIs instead of incidental helper methods.

Aggregate packages are curated installation shortcuts

The two *.App packages are important because they are not new runtime layers. Cuemon.Core.App and Cuemon.AspNetCore.App are metadata-only convenience packages that gather a broader set of focused packages into one install choice. Use them when a solution intentionally wants the wider curated surface; otherwise start from the smaller package that owns the actual API you plan to call.

Usage guidance

Start from the smallest package that owns the contract you need, then add the nearest adapter layer only when the surrounding framework boundary requires it. For example, pick Cuemon.Kernel or Cuemon.Core for shared primitives, move to focused domains like Cuemon.Data, Cuemon.Runtime.Caching, Cuemon.Xml, or Cuemon.Net when the workflow boundary is clear, and only then add extensions such as Cuemon.Extensions.DependencyInjection, Cuemon.Extensions.Text.Json, or Cuemon.Extensions.AspNetCore when you actually need DI, formatter, or ASP.NET Core integration.

Avoid taking the broader package just because it exists. Do not install Cuemon.Core.App or Cuemon.AspNetCore.App when only one or two focused packages are in play. Do not bring in MVC formatter packages when formatter options alone are enough, and do not wrap non-idempotent work in Cuemon.Resilience just because retries are available. The safe default is to choose the package that defines the behavior you are coding against, then step up one layer only when a host, transport, or serializer boundary needs the adapter.