✨ Atya Libraries

Focused, composable, production-minded building blocks for modern .NET

Atya Libraries is a growing ecosystem of .NET 10 libraries, developer tools, templates, and shared engineering infrastructure published under the Atya.* package prefix.

Explore packages · Choose a package · View the architecture · Start a repository · Contribute

Atya Libraries provides small, explicit packages that can be adopted independently or composed into a consistent application platform.

The ecosystem is designed around a few principles:

• Focused packages — each repository owns a narrow, understandable responsibility.
• Provider-neutral foundations — core contracts avoid unnecessary framework and vendor coupling.
• Explicit outcomes — expected failures can be represented with Result and Error values instead of exception-driven control flow.
• Clear boundaries — application, diagnostics, HTTP, web, validation, and build concerns remain separate.
• Production-minded defaults — deterministic builds, package validation, dependency auditing, SourceLink, symbols, and automated release workflows.
• Consistent developer experience — shared build policy, analyzers, tests, templates, CI workflows, dependency updates, and release checks.

dotnet add package Atya.Foundation.Results

dotnet add package Atya.Web.Middleware

dotnet add package Atya.Diagnostics.OpenTelemetry

dotnet tool install --global Atya.Tooling.Cli
atya doctor

dotnet new install Atya.Templates.NuGetPackage
dotnet new atya-nuget --name Foundation.Caching --output Atya.Foundation.Caching

Browse all published packages on NuGet or use the Atya package catalog.

The following diagram shows the conceptual composition of the main package families. Arrows represent an integration or common composition path, not a requirement to install every connected package.

flowchart LR
    subgraph Foundation["🧱 Foundation"]
        A["Abstractions"]
        P["Primitives"]
        G["Guards"]
        T["Time"]
        S["Serialization"]
        R["Results"]
    end

    subgraph Errors["🛡️ Errors"]
        E["Exceptions"]
        V["Validation"]
        PD["ProblemDetails"]
    end

    subgraph Application["🧠 Application"]
        M["Mediator"]
    end

    subgraph Diagnostics["📡 Diagnostics"]
        L["Logging"]
        ME["Metrics"]
        TR["Tracing"]
        O["Observation"]
        OT["OpenTelemetry"]
    end

    subgraph Web["🌐 Web & HTTP"]
        MW["Middleware"]
        H["HealthChecks"]
        C["HTTP Client"]
    end

    A --> P
    R --> V
    E --> V
    R --> PD
    E --> PD
    R --> M
    PD --> MW
    R --> C
    PD --> C
    L --> O
    ME --> O
    TR --> O
    L --> OT
    ME --> OT
    TR --> OT

    classDef foundation fill:#512BD4,color:#fff,stroke:#32156f
    classDef errors fill:#DC2626,color:#fff,stroke:#7f1d1d
    classDef application fill:#7C3AED,color:#fff,stroke:#4c1d95
    classDef diagnostics fill:#0284C7,color:#fff,stroke:#075985
    classDef web fill:#059669,color:#fff,stroke:#065f46

    class A,P,G,T,S,R foundation
    class E,V,PD errors
    class M application
    class L,ME,TR,O,OT diagnostics
    class MW,H,C web

Package	Repository	Purpose
	Abstractions	Provider-neutral contracts for IDs, entities, auditing, soft deletion, paging, and result-like models.
	Primitives	Low-level primitives including errors, results, value objects, strongly typed IDs, and paging models.
	Guards	Lightweight guard clauses for arguments and low-level invariants.
	Time	UTC-safe clock abstractions and UTC input validation.
	Serialization	Shared System.Text.Json defaults and configuration helpers.
	Results	Focused Result and Error primitives for expected, recoverable outcomes.

Package	Repository	Purpose
	Exceptions	Reusable exception taxonomy without HTTP or transport coupling.
	Validation	Validation contracts, models, composition, and conversion to Atya Results or exceptions.
	ProblemDetails	ASP.NET Core ProblemDetails responses and exception/Result mapping at the HTTP boundary.
	Mediator	Source-generated, reflection-free mediator contracts and Result-first dispatch.

Package	Repository	Purpose
	Logging	Provider-agnostic structured logging helpers.
	Metrics	Metrics helpers built on System.Diagnostics.Metrics.
	Tracing	Tracing helpers built on System.Diagnostics.Activity.
	Observation	Thin composition over Atya logging, metrics, and tracing.
	OpenTelemetry	Host-facing OpenTelemetry SDK setup, resource metadata, instrumentation, and OTLP configuration.

Package	Repository	Purpose
	Middleware	ASP.NET Core adapters for Atya exceptions, Results, and ProblemDetails.
	HealthChecks	Standard health, liveness, and readiness endpoint helpers.
	Client	Typed HttpClient helpers with Results, ProblemDetails mapping, and correlation propagation.

Package	Repository	Purpose
	Testing	Test-only clocks, correlation/user fakes, JSON assertions, Result assertions, and validation builders.
	CodeQuality	Centralized analyzers, StyleCop rules, and C# code-style policy through buildTransitive.
	Atya.Build.Sdk	Shared build, packaging, SourceLink, MinVer, naming, test, and NuGet metadata defaults.
	Cli	Read-only repository conformance, release preflight, and post-release verification commands.

Package	Repository	Purpose
	NuGet package template	Production-ready .NET package repository template with tests, samples, benchmarks, CI, and publishing integration.
	UI automation template	.NET 10, Playwright, xUnit v3, and Microsoft Testing Platform solution template.

Atya is more than a package catalog. The organization maintains a shared engineering platform that helps repositories behave consistently.

Atya.Build.Sdk centralizes conditional defaults for:

• target framework and language settings;
• nullable reference types and implicit usings;
• deterministic builds and warnings-as-errors;
• NuGet auditing and lock files;
• package naming and metadata validation;
• SourceLink, symbols, documentation, and package validation;
• common test-project dependencies and configuration.

{
  "msbuild-sdks": {
    "Atya.Build.Sdk": "<version>"
  }
}

<Project Sdk="Atya.Build.Sdk">
  <PropertyGroup>
    <PackageId>Atya.Foundation.Example</PackageId>
    <AssemblyName>Atya.Foundation.Example</AssemblyName>
    <RootNamespace>Atya.Foundation.Example</RootNamespace>
    <Description>Example Atya package.</Description>
    <Authors>AtyaLibraries</Authors>
    <RepositoryUrl>https://github.com/AtyaLibraries/Example</RepositoryUrl>
  </PropertyGroup>
</Project>

Atya.Governance.CodeQuality distributes analyzer and StyleCop policy through a private build-only package reference:

<PackageReference
  Include="Atya.Governance.CodeQuality"
  Version="<version>"
  PrivateAssets="all" />

The atya CLI performs deterministic, read-only checks:

atya doctor
atya release check --online --version <version>
atya release verify --online --version <version>

The tool diagnoses repository and release state; it intentionally does not publish packages, create tags, rewrite repositories, or manage secrets.

# NuGet package repository
dotnet new install Atya.Templates.NuGetPackage
dotnet new atya-nuget --name Foundation.Caching

# UI automation solution
dotnet new install Atya.Templates.UiAutomation
dotnet new atya-ui-automation --name Contoso.Shop.UiAutomation

The exact gates are repository-specific, but the shared Atya platform is designed to support a consistent release baseline:

restore in locked mode
        ↓
dependency vulnerability audit
        ↓
format and analyzer verification
        ↓
deterministic Release build
        ↓
unit tests and configured coverage gates
        ↓
NuGet package validation
        ↓
.nupkg + .snupkg artifacts
        ↓
protected central publishing through OIDC
        ↓
NuGet package + GitHub release

Common platform capabilities include:

• reusable CI workflows pinned by release tags;
• CodeQL and dependency-review workflows;
• deterministic builds with SourceLink and symbols;
• locked dependency graphs and vulnerability auditing;
• immutable SemVer package releases;
• centralized trusted publishing without repository-level NuGet API keys;
• Renovate-driven dependency and lock-file maintenance;
• package naming and metadata guards.

A typical Atya package repository follows this shape:

src/<Package>/                    shipped library or tool
tests/<Package>.UnitTests/        automated behavioral coverage
samples/<Package>.Samples.*/      runnable consumer examples
benchmarks/<Package>.Benchmarks/  BenchmarkDotNet harness
.github/workflows/                CI, security, and release entry points
README.md                         maintainer and contributor documentation
LICENSE                           package license

Common conventions:

• NuGet package IDs use the Atya.{Area}.{Name} family where applicable.
• Package, assembly, and root namespace identities are intentionally aligned.
• Packages target modern .NET and currently standardize on .NET 10.
• Public package APIs remain small and boundary-focused.
• Consumer documentation lives with the package and is included in NuGet packages where appropriate.
• Individual repositories are versioned and released independently.

Contributions are welcome across the ecosystem.

1. Choose the repository that owns the behavior or package boundary.
2. Read its README and repository-specific development instructions.
3. Keep changes focused and avoid introducing dependencies outside the package's responsibility.
4. Add or update tests, samples, documentation, and public API tracking where required.
5. Run the repository's restore, format, build, test, audit, and pack checks.
6. Open a clear pull request describing the problem, solution, compatibility impact, and validation performed.

For bugs and feature proposals, open an issue in the relevant repository so the discussion stays close to the code and release history.

• 🌐 Atya Libraries website and package catalog
• 📦 Search all Atya.* packages on NuGet
• 👤 NuGet publisher profile
• 🗃️ Browse organization repositories
• 🗺️ Atya Platform project board
• 🧰 Create a package with the Atya template
• ✅ Validate a repository with the Atya CLI

Atya library repositories are released under the MIT License unless a repository explicitly states otherwise. See the LICENSE file in each repository for the authoritative terms.