Forem: Tatted Dev

🍯 Announcing HoneyDrunk.Data: A Multi-Tenant Persistence Layer for Distributed .NET Applications

Tatted Dev — Tue, 06 Jan 2026 23:34:07 +0000

TL;DR: We just released HoneyDrunk.Data, a provider-agnostic persistence layer built for multi-tenant, distributed .NET 10 applications. It features automatic correlation tracking in SQL queries, tenant-aware repositories, and seamless integration with OpenTelemetry—all without coupling your domain logic to Entity Framework.

The Problem We're Solving

Building multi-tenant applications with proper observability is harder than it should be. You end up with:

Scattered tenant checks throughout your codebase
No correlation between your distributed traces and database queries
Tight coupling between your domain logic and EF Core
Test infrastructure that requires spinning up real databases

We built HoneyDrunk.Data to solve these problems as part of HoneyDrunk.OS—our distributed application framework for .NET.

Architecture: Layers That Actually Make Sense

┌─────────────────────────────────────┐
│   HoneyDrunk.Data.Abstractions      │  ← Zero EF Core dependencies
│   (IRepository, IUnitOfWork, etc.)  │
└─────────────────────────────────────┘
                  │
                  ▼
┌─────────────────────────────────────┐
│        HoneyDrunk.Data              │  ← Kernel integration, no EF Core
│   (Tenant accessor, telemetry)      │
└─────────────────────────────────────┘
                  │
                  ▼
┌─────────────────────────────────────┐
│  HoneyDrunk.Data.EntityFramework    │  ← EF Core implementation
│   (EfRepository, EfUnitOfWork)      │
└─────────────────────────────────────┘
                  │
                  ▼
┌─────────────────────────────────────┐
│    HoneyDrunk.Data.SqlServer        │  ← SQL Server specifics
│   (Retry, Azure SQL, datetime2)     │
└─────────────────────────────────────┘

Why this matters: Your domain projects reference only HoneyDrunk.Data.Abstractions. No EF Core leaking into your business logic. Swap providers without touching domain code.

Feature Highlight: Correlation Tracking in SQL

This is my favorite feature. Every SQL command is automatically tagged with the Grid correlation ID:

/* correlation:01JXY7ABC123DEF456 */
SELECT [o].[Id], [o].[CustomerId], [o].[Total]
FROM [Orders] AS [o]
WHERE [o].[TenantId] = @p0

Why it matters:

Find the exact query from a slow API response
Correlate database logs with distributed traces
Debug production issues without guessing

The implementation uses EF Core's DbCommandInterceptor:

public sealed class CorrelationCommandInterceptor : DbCommandInterceptor
{
    private readonly IDataDiagnosticsContext _diagnosticsContext;

    public override InterceptionResult<int> NonQueryExecuting(
        DbCommand command,
        CommandEventData eventData,
        InterceptionResult<int> result)
    {
        AddCorrelationComment(command);
        return base.NonQueryExecuting(command, eventData, result);
    }

    private void AddCorrelationComment(DbCommand command)
    {
        var correlationId = _diagnosticsContext.CorrelationId;
        if (string.IsNullOrEmpty(correlationId)) return;

        // SQL comments don't affect query plan caching
        command.CommandText = $"/* correlation:{correlationId} */\n{command.CommandText}";
    }
}

We use SQL comments specifically because they don't affect query plan caching—your cached plans stay cached.

Multi-Tenancy: From HTTP Header to Database Query

Tenant context flows automatically from the HTTP request through to database queries:

HTTP Request                 Kernel                    Data Layer
     │                         │                          │
X-Tenant-Id: acme  →  IOperationContext.TenantId  →  ITenantAccessor
     │                         │                          │
                                                   TenantId.FromString("acme")

The KernelTenantAccessor bridges our Kernel context system with the data layer:

public sealed class KernelTenantAccessor : ITenantAccessor
{
    private readonly IOperationContextAccessor _contextAccessor;

    public TenantId GetCurrentTenantId()
    {
        var tenantId = _contextAccessor.CurrentContext?.TenantId;
        return string.IsNullOrEmpty(tenantId) 
            ? default 
            : TenantId.FromString(tenantId);
    }
}

Your DbContext can then apply global query filters:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // Every query automatically filters by tenant
    modelBuilder.Entity<Order>()
        .HasQueryFilter(o => o.TenantId == CurrentTenantId.Value);
}

No more "did we remember to filter by tenant?" code reviews.

The Repository Pattern, Done Right

I know, I know—"repository pattern is an anti-pattern with EF Core." Hear me out.

Our repositories aren't about abstracting EF Core. They're about:

Separating read from write concerns
Providing a testable boundary
Enabling future provider swaps (Dapper for hot paths, anyone?)

public interface IReadOnlyRepository<TEntity>
{
    ValueTask<TEntity?> FindByIdAsync(object id, CancellationToken ct = default);
    Task<IReadOnlyList<TEntity>> FindAsync(Expression<Func<TEntity, bool>> predicate, CancellationToken ct = default);
    Task<bool> ExistsAsync(Expression<Func<TEntity, bool>> predicate, CancellationToken ct = default);
}

public interface IRepository<TEntity> : IReadOnlyRepository<TEntity>
{
    Task AddAsync(TEntity entity, CancellationToken ct = default);
    void Update(TEntity entity);
    void Remove(TEntity entity);
}

The Unit of Work coordinates changes:

public async Task CheckoutAsync(Cart cart, CancellationToken ct)
{
    var orders = _unitOfWork.Repository<Order>();
    var inventory = _unitOfWork.Repository<InventoryItem>();

    var order = new Order { Items = cart.Items };
    await orders.AddAsync(order, ct);

    foreach (var item in cart.Items)
    {
        var inv = await inventory.FindByIdAsync(item.ProductId, ct);
        inv!.Quantity -= item.Quantity;
        inventory.Update(inv);
    }

    // Atomic save across all repositories
    await _unitOfWork.SaveChangesAsync(ct);
}

Testing Without Docker: SQLite In-Memory

Spinning up SQL Server containers for every test run is slow. We provide SQLite-based test infrastructure:

public class OrderRepositoryTests : IAsyncDisposable
{
    private readonly SqliteTestDbContextFactory<AppDbContext> _factory;
    private readonly AppDbContext _context;

    public OrderRepositoryTests()
    {
        _factory = new SqliteTestDbContextFactory<AppDbContext>(
            options => new AppDbContext(
                options,
                TestDoubles.CreateTenantAccessor("test-tenant"),
                TestDoubles.CreateDiagnosticsContext()));

        _context = _factory.Create();
    }

    [Fact]
    public async Task AddAsync_ShouldPersistOrder()
    {
        var repo = new EfRepository<Order, AppDbContext>(_context);
        var order = new Order { Id = Guid.NewGuid(), Total = 99.99m };

        await repo.AddAsync(order);
        await _context.SaveChangesAsync();

        var found = await repo.FindByIdAsync(order.Id);
        Assert.NotNull(found);
    }

    public async ValueTask DisposeAsync()
    {
        await _context.DisposeAsync();
        await _factory.DisposeAsync();
    }
}

Test doubles included for tenant and diagnostics contexts—no mocking frameworks required.

SQL Server Specifics: datetime2 and Retry Logic

The HoneyDrunk.Data.SqlServer package handles SQL Server-specific concerns:

builder.Services.AddHoneyDrunkDataSqlServer<AppDbContext>(options =>
{
    options.ConnectionString = config.GetConnectionString("Default");
    options.EnableRetryOnFailure = true;
    options.MaxRetryCount = 3;
});

// Or for Azure SQL with optimized settings
builder.Services.AddHoneyDrunkDataAzureSql<AppDbContext>(options =>
{
    options.ConnectionString = config.GetConnectionString("AzureSql");
});

Model conventions automatically apply SQL Server best practices:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder
        .UseDateTime2ForAllDateTimeProperties()  // No more datetime truncation
        .ConfigureDecimalPrecision(18, 4);       // Explicit money precision
}

Getting Started

# Full stack with SQL Server
dotnet add package HoneyDrunk.Data.SqlServer

# Or just EF Core (bring your own provider)
dotnet add package HoneyDrunk.Data.EntityFramework

# Or abstractions only (for domain libraries)
dotnet add package HoneyDrunk.Data.Abstractions

Minimal setup:

var builder = WebApplication.CreateBuilder(args);

// Register Kernel (required for context propagation)
builder.Services.AddHoneyDrunkGrid(options =>
{
    options.NodeId = "order-service";
    options.StudioId = "acme-corp";
});

// Register Data layer
builder.Services.AddHoneyDrunkData();
builder.Services.AddHoneyDrunkDataSqlServer<AppDbContext>(options =>
{
    options.ConnectionString = builder.Configuration.GetConnectionString("Default");
});

var app = builder.Build();

app.MapGet("/orders/{id}", async (Guid id, IUnitOfWork<AppDbContext> unitOfWork) =>
{
    var order = await unitOfWork.Repository<Order>().FindByIdAsync(id);
    return order is not null ? Results.Ok(order) : Results.NotFound();
});

app.Run();

What's Next?

This is v0.1.0—the foundation. On the roadmap:

PostgreSQL provider (HoneyDrunk.Data.PostgreSQL)
Read replica support for CQRS patterns
Outbox pattern integration for reliable messaging
Query profiling with automatic slow query detection

HoneyDrunk.Transport: A Transport Agnostic Messaging Framework for .NET

Tatted Dev — Mon, 08 Dec 2025 13:56:08 +0000

Distributed systems love to trap you in vendor gravity. One transport today becomes a rewrite tomorrow. When I started wiring together services for HoneyDrunk’s distributed grid, the usual messaging libraries all had the same problem: coupling. Everything leaked broker assumptions.

So I built HoneyDrunk.Transport to break that pattern.

What It Is

HoneyDrunk.Transport is a transport-agnostic messaging abstraction for .NET. Your code looks identical whether you're using Azure Service Bus, Azure Storage Queues, or the InMemory transport.

// This code works identically whether you're using
// Azure Service Bus, Storage Queues, or InMemory transport
public class OrderService(IMessagePublisher publisher, IGridContext gridContext)
{
    public async Task CreateOrderAsync(Order order, CancellationToken ct)
    {
        await publisher.PublishAsync(
            destination: "orders.created",
            message: new OrderCreated(order.Id, order.CustomerId),
            gridContext: gridContext,
            cancellationToken: ct);
    }
}

Your handlers stay the same too.

public class OrderCreatedHandler : IMessageHandler<OrderCreated>
{
    public async Task<MessageProcessingResult> HandleAsync(
        OrderCreated message,
        MessageContext context,
        CancellationToken ct)
    {
        var correlationId = context.GridContext?.CorrelationId;
        var tenantId = context.GridContext?.TenantId;

        await ProcessOrderAsync(message, ct);
        return MessageProcessingResult.Success;
    }
}

Why It Exists

1. Swap transports without rewriting code

// Development
services.AddHoneyDrunkTransportCore()
    .AddHoneyDrunkInMemoryTransport();

// Production
services.AddHoneyDrunkTransportCore()
    .AddHoneyDrunkServiceBusTransport(options => 
    {
        options.FullyQualifiedNamespace = "mynamespace.servicebus.windows.net";
        options.Address = "orders-queue";
    });

2. Distributed context propagation

Node A (Order Service)                    Node B (Payment Service)
┌─────────────────────┐                   ┌─────────────────────┐
│ CorrelationId: abc  │ ──── Queue ────▶  │ CorrelationId: abc  │
│ TenantId: tenant-1  │                   │ TenantId: tenant-1  │
│ ProjectId: proj-1   │                   │ ProjectId: proj-1   │
└─────────────────────┘                   └─────────────────────┘

3. Middleware pipeline

services.AddHoneyDrunkTransportCore(options =>
{
    options.EnableTelemetry = true;   // OpenTelemetry spans
    options.EnableLogging = true;     // Structured logging
    options.EnableCorrelation = true; // Grid context propagation
});

// Add custom middleware
services.AddMessageMiddleware<TenantResolutionMiddleware>();

4. Configurable error handling

var strategy = new ConfigurableErrorHandlingStrategy(maxDeliveryCount: 5)
    .RetryOn<TimeoutException>(TimeSpan.FromSeconds(5))
    .RetryOn<HttpRequestException>(TimeSpan.FromSeconds(10))
    .DeadLetterOn<ValidationException>()
    .DeadLetterOn<ArgumentNullException>();

services.AddSingleton<IErrorHandlingStrategy>(strategy);

Architecture at a Glance

┌─────────────────────────────────────────────────────────────────┐
│                     Your Application                            │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐ │
│  │ OrderService    │  │ PaymentHandler  │  │ Custom          │ │
│  │ (IMessagePub)   │  │ (IMessageHandler)│ │ Middleware      │ │
│  └────────┬────────┘  └────────┬────────┘  └────────┬────────┘ │
└───────────┼─────────────────────┼─────────────────────┼─────────┘
            │                     │                     │
┌───────────▼─────────────────────▼─────────────────────▼─────────┐
│                   HoneyDrunk.Transport                          │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐          │
│  │ Abstractions │  │   Pipeline   │  │ Configuration│          │
│  │ IMessagePub  │  │  Middleware  │  │ ErrorStrategy│          │
│  │ IMessageHdlr │  │  Telemetry   │  │ RetryOptions │          │
│  └──────────────┘  └──────────────┘  └──────────────┘          │
└─────────────────────────────┬───────────────────────────────────┘
                              │
        ┌─────────────────────┼─────────────────────┐
        ▼                     ▼                     ▼
┌───────────────┐    ┌───────────────┐    ┌───────────────┐
│ ServiceBus    │    │ StorageQueue  │    │   InMemory    │
│   Transport   │    │   Transport   │    │   Transport   │
└───────────────┘    └───────────────┘    └───────────────┘

Transport Adapters

Azure Service Bus

services.AddHoneyDrunkServiceBusTransport(options =>
{
    options.FullyQualifiedNamespace = "mynamespace.servicebus.windows.net";
    options.EntityType = ServiceBusEntityType.Topic;
    options.Address = "orders-topic";
    options.SubscriptionName = "order-processor";
    options.MaxConcurrency = 10;

    // Blob fallback for large messages
    options.BlobFallback.Enabled = true;
    options.BlobFallback.AccountUrl = "https://myaccount.blob.core.windows.net";
});

Azure Storage Queue

services.AddHoneyDrunkStorageQueueTransport(options =>
{
    options.ConnectionString = "...";
    options.QueueName = "notifications";
    options.MaxConcurrency = 10;
    options.BatchProcessingConcurrency = 4;  // 40 total concurrent
});

InMemory Transport

services.AddHoneyDrunkTransportCore()
    .AddHoneyDrunkInMemoryTransport();

Try It Out

dotnet add package HoneyDrunk.Transport
dotnet add package HoneyDrunk.Transport.AzureServiceBus
dotnet add package HoneyDrunk.Transport.StorageQueue
dotnet add package HoneyDrunk.Transport.InMemory

Final Notes

HoneyDrunk.Transport exists because messaging shouldn’t require allegiance to a single broker. If you want clean abstractions, portable handlers, built-in telemetry, and automatic context propagation, it’s worth exploring.

If you try it, let me know how it fits into your stack.

Originally published on TattedDev.com

Honeypunk: A Semantic, Palette-Driven Theme Pipeline for Visual Studio 2026

Tatted Dev — Sun, 16 Nov 2025 20:43:39 +0000

Visual Studio 2026 shipped last week, and like a lot of devs, I installed it immediately. The new UI polish looked great. The editor surfaces felt modern. Then I opened a file and hit something familiar:

My favorite themes had not updated.

No previews. No experimental builds. No support for the new classification keys introduced in VS2026.

Instead of waiting, I built the update myself and, in the process, created a full semantic theme pipeline.

Honeypunk is a palette-driven, YAML-based system that lets you define color intent once and generate a complete Visual Studio theme automatically. No hex hunting. No drift. No fragile edits.

Repository: https://github.com/tatteddev/Honeypunk

Why Manual Theme Editing Fails

Visual Studio theming is powerful but tedious. Updating themes manually is slow and error prone, especially when a major version adds new editor surfaces.

Common issues include:

Hex values scattered across huge JSON theme files
Small tweaks creating near-duplicate colors
New VS releases breaking old themes
One color change often requiring 20 or more key edits
No auditing for unused or duplicate colors
Experimentation requiring too much overhead

Honeypunk introduces a semantic, declarative approach that avoids all of this.

The Pipeline Model

Honeypunk follows a predictable, declarative flow:

Palette → Roles → Mappings → Build → VSIX

Palette

The palette is the root of the system. All colors are centralized into a single file with:

Human-readable names
Contrast rules
Usage intent (foreground, accent, diagnostic, background)
Structure that allows global shifts with a single edit

Roles

Roles describe what a token represents, not what color it uses. Examples:

function
variable
type
interface
keyword
comment
string
operator

Roles point to palette entries, never hex values.

Mappings

Mappings connect semantic roles to actual Visual Studio classification keys. This file handles:

VS2022 through VS2026 classifications
ReSharper keys
Background and foreground tokens
New surfaces introduced by 2026

Build Scripts

The Python tooling:

Loads palette, roles, mappings
Resolves semantic intent to actual colors
Validates for errors, typos, unmapped items
Preserves flags like transparency
Generates a deterministic theme file

VSIX

The final packaging step creates a distributable Visual Studio extension supporting:

VS2022
VS2025
VS2026

The entire pipeline allows rebuilds in seconds.

Core Files

Honeypunk.yaml

Defines high-level theme structure:

Editor
Chrome and toolbars
Tool windows
Accent states
Debugging and caret surfaces
Selection and inlay hints

palette.md

A complete list of named colors with:

Hex values
Usage recommendations
Contrast notes
Accessibility considerations

roles.yaml

Maps semantic intent to palette names, for example:

functions: NeonYellow

variables: ChromeTeal

comments: SlateGray

mappings.yaml

Links roles to actual Visual Studio classification keys.

apply_palette.py

Reads all YAML files, applies semantic roles, enforces safety checks, and produces the resolved theme.

build_vsix.py

Packages the final theme into a VSIX with the necessary manifest metadata.

Palette Philosophy

The Honeypunk palette is intentionally structured for clarity and reduced fatigue.

Background tier

Deep gunmetal and charcoal tones that minimize glare.

Text tier

Neutral off-white and slate values optimized for long reading sessions.

Accent tier

Electric blues, neon yellows, and magentas used sparingly and intentionally.

Diagnostic triad

Orange for warnings
Magenta for attention
Green for success

The palette supports fast code scanning and visual consistency across large files.

Updating for Visual Studio 2026

VS2026 introduced new:

Classification keys
Chrome surfaces
Editor states
Accent highlights

A manual update would require reviewing every affected surface.

Honeypunk reduced this to a few mapping adjustments and a single rebuild.

Extending the System

Honeypunk was built for growth.

Adding a new role

Add to roles.yaml and map in mappings.yaml.

Adding a new color

Add to palette.md and reference it in roles.

Multiple theme variants

Create separate YAML build configurations sharing the same palette.

Coming soon

Accessibility variants
JSON diff reports
Live preview experiments
CI checks for color drift

Troubleshooting

Common fixes:

Theme not showing: verify VSIX manifest GUID.
Odd colors: check palette name for typos.
Build failure: YAML indentation error.
Missing token updates: mapping entry missing.

Try It Yourself

Clone the repo and modify a single role.

Rebuild the VSIX.

Install and restart Visual Studio.

You will immediately see how semantic theming makes iteration effortless.

Repository: https://github.com/tatteddev/Honeypunk

Originally published at:

https://tatteddev.com/blog/honeypunk-semantic-theme-pipeline-vs2026/

Building a Zero-Configuration .NET Standards Package

Tatted Dev — Mon, 03 Nov 2025 21:58:37 +0000

Posted by TattedDev

The Problem With Code Standards

Every .NET organization eventually fights the same battle: keeping code quality consistent across dozens of solutions. You copy .editorconfig files, manually add analyzers, and hope developers remember to fix warnings. Over time, configurations drift, rules diverge, and build quality becomes uneven.

HoneyDrunk.Standards solves this by turning code quality into infrastructure. It’s a single NuGet package that enforces conventions, analyzers, and build configurations automatically across every project in your ecosystem.

How It Works

1. Build-Transitive Package Design

The package uses MSBuild’s buildTransitive feature, which allows its build logic to propagate to all downstream projects that reference it.

Unlike normal runtime packages, this one operates entirely at build time.

When referenced, it automatically:

Enables StyleCop.Analyzers and Microsoft.CodeAnalysis.NetAnalyzers
Enforces nullable reference types
Treats warnings as errors in CI environments
Enables deterministic builds
Locks C# language version to latest

You don’t modify your .csproj. You don’t merge .editorconfig. It’s zero-configuration by design.

2. Continuous Integration Awareness

The package detects CI systems (like GitHub Actions or Azure Pipelines) through environment variables and automatically enables ContinuousIntegrationBuild=true.

This provides two distinct build profiles:

Local development: fast incremental builds with absolute source paths for debugging
CI builds: deterministic, reproducible outputs with embedded source paths for traceability

The result is parity between developer machines and build servers without requiring conditional logic in your projects.

3. Opt-Out Instead of Opt-In

Every enforcement feature is enabled by default.

Developers can selectively disable rules via MSBuild properties, but the baseline assumes quality enforcement. This approach prevents “silent drift” where one repository quietly stops following standards.

Opt-out defaults ensure consistency across all solutions while maintaining flexibility for legitimate edge cases.

Why This Approach Works

Consistent Code Quality

StyleCop.Analyzers enforces over 100 naming, spacing, and ordering rules
Microsoft.CodeAnalysis.NetAnalyzers enforces performance, security, and reliability best practices
Violations fail CI builds automatically, maintaining organizational quality thresholds

Configuration Centralization

One version bump updates analyzers, language rules, and conventions across every project.

No more synchronizing .editorconfig files or manually aligning rule sets across repositories.

Faster Onboarding

New developers get immediate feedback inside Visual Studio or Rider.

Standards become visible and actionable in the IDE instead of hidden in documentation.

Deterministic and Auditable Builds

Every project builds reproducibly, producing identical binaries for the same source inputs.

That’s essential for compliance, debugging, and verifying production deployments.

Common Gotchas and Solutions

1. Large Warning Backlogs

Adding the package to a legacy project often triggers hundreds of analyzer warnings.

Use incremental adoption:

<NoWarn>$(NoWarn);SA*</NoWarn>

Then remove suppression rules as you clean up the codebase.

2. Missing `PrivateAssets="all"`

Omitting this property allows analyzers to flow transitively into your consumers, which is rarely desirable.

Always declare:

<PackageReference Include="HoneyDrunk.Standards" PrivateAssets="all" />

This prevents analyzer propagation and keeps the standards internal to your organization.

3. Test Method Naming (CA1707)

Unit test naming conventions like MethodName_Condition_ExpectedResult conflict with CA1707.

The package pre-suppresses this rule, prioritizing readability and established testing patterns.

4. Overuse of the Null-Forgiving Operator (`!`)

The null-forgiving operator should be reserved for proven non-null scenarios.

Document any usage with an inline comment explaining why null cannot occur.

5. Local vs CI Output Differences

When running locally, builds embed absolute file paths.

In CI mode, paths are normalized for reproducibility.

To simulate CI locally:

dotnet build /p:ContinuousIntegrationBuild=true

6. Team Preference Conflicts

Different teams sometimes prefer conflicting style rules (for example, requiring or omitting this. prefixes).

The package allows per-project overrides in .editorconfig, and StyleCop can be disabled completely if needed:

<PropertyGroup>
  <EnableStyleCopAnalyzers>false</EnableStyleCopAnalyzers>
</PropertyGroup>

Implementation Best Practices

Start with a sample project. The included Consumer.Sample demonstrates compliant patterns and deliberate violations.
Document your rationale. The CONVENTIONS.md file explains why specific rules exist.
Use versioning semantics.
- Minor version → new rules or non-breaking changes
- Major version → breaking rule severity or enforcement changes

Treat standards packages as infrastructure, not libraries. They’re a versioned part of your build system.

Key Takeaways

Build-transitive packages are the cleanest way to enforce organization-wide build and analyzer standards.
Default-on enforcement guarantees consistency.
Gradual adoption keeps legacy code manageable.
Documentation matters as much as enforcement.
PrivateAssets="all" prevents downstream dependency pollution.

Try It Yourself

<PackageReference Include="HoneyDrunk.Standards" PrivateAssets="all" />

That single line brings your organization in line with modern, deterministic .NET build standards.

Repository: github.com/HoneyDrunkStudios/HoneyDrunk.Standards

Docs: Conventions guide, naming policies, nullable handling, and migration strategies.

Have you implemented your own internal standards package? What challenges did you hit during rollout? Share them below — the goal is a future where “code style review” isn’t a recurring meeting topic.

🟡 Written by TattedDev — building the HoneyDrunk ecosystem, one node at a time.

HoneyDrunk.Pipelines — Treat Your CI/CD as Infrastructure

Tatted Dev — Sat, 11 Oct 2025 21:02:40 +0000

When you’re a small team—or even a solo dev—the friction of managing CI/CD pipelines across multiple repos adds up fast.

A missing permission, a stale PAT, or a malformed GUID can break your release.

That’s what pushed me to think differently: treat pipeline configuration like infrastructure you version, maintain, and compose.

In this post, I’ll walk through how I built HoneyDrunk.Pipelines, a centralized, reusable template system for Azure DevOps, and the lessons that came out of it.

🧠 The Problem: Pipeline Sprawl & Runtime Breakage

Before building a unified system, here’s what I was dealing with:

Every repo had its own azure-pipelines.yml, each slightly different
Copy-pasted feed GUIDs, mismatched naming, and inconsistent versioning
Permission and service connection issues that only surfaced at runtime
Changing SDK versions or build logic meant updating several repos manually

A single pipeline failure captured the pain perfectly:

The build service identity didn’t have Contributor on the feed
The service connection used a stale PAT
The feed URL (with GUID) was mis-typed

Each of these were independent problems that only appeared after I pushed.

That’s when I decided: pipelines can’t be snowflakes anymore.

⚙️ The Vision: Pipelines as Reusable Infrastructure

I wrote down a few core principles before rebuilding:

Single source of truth. One repo for templates, many consumers
Versioned logic. Pipeline changes are reviewed and auditable
Composable building blocks. Stages, jobs, and steps can be mixed and matched
Separation of concerns. Projects define what to build; templates define how to build

🗂️ Repository Layout (Simplified)

HoneyDrunk.Pipelines/
├── stages/
├── jobs/
├── steps/
└── README.md

ConsumerRepo/
└── azure-pipelines.yml # references templates from HoneyDrunk.Pipelines

Consumer repos reference the template repo via Azure DevOps resources:

resources:
  repositories:
    - repository: pipelines
      type: git
      name: HoneyDrunk/HoneyDrunk.Pipelines
      ref: refs/heads/main

stages:
  - template: stages/pr-validation.stage.yaml@pipelines
    parameters:
      projectPath: 'src/MyLib/MyLib.csproj'
      runTests: true

  - template: stages/dotnet-publish.stage.yaml@pipelines
    parameters:
      dependsOn: PR_Validation
      condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
      packagePath: '$(Build.ArtifactStagingDirectory)/**/*.nupkg'
      feedName: 'HoneyDrunk-Internal'


That’s about 10 lines of YAML per project — the rest lives in the infrastructure layer.

🧩 Core Template Mechanics
PR Validation Stage
parameters:
  - name: projectPath
    type: string
  - name: configuration
    type: string
    default: 'Release'
  - name: runTests
    type: boolean
    default: true
  - name: dotnetVersion
    type: string
    default: '9.x'

stages:
  - stage: PR_Validation
    displayName: 'Build, Test, Validate'
    jobs:
      - job: Build
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - template: ../steps/install-dotnet-sdk.step.yaml
            parameters:
              dotnetVersion: ${{ parameters.dotnetVersion }}
          - template: ../steps/dotnet-restore-build.step.yaml
          - template: ../steps/dotnet-build.step.yaml
            parameters:
              projectPath: ${{ parameters.projectPath }}
              configuration: ${{ parameters.configuration }}
          - ${{ if eq(parameters.runTests, true) }}:
            - template: ../steps/dotnet-test.step.yaml
          - template: ../steps/dotnet-pack.step.yaml
            parameters:
              projectPath: ${{ parameters.projectPath }}
              configuration: ${{ parameters.configuration }}

Each step is modular, reusable, and easy to evolve.

Package Publish Step
parameters:
  - name: packagePath
    type: string
  - name: feedName
    type: string
  - name: serviceConnection
    type: string
    default: 'HoneyDrunk-AzureDevOps'

steps:
  - task: NuGetAuthenticate@1
    displayName: 'Authenticate with Azure Artifacts'
    inputs:
      nuGetServiceConnections: ${{ parameters.serviceConnection }}

  - task: DotNetCoreCLI@2
    displayName: 'Push to ${{ parameters.feedName }}'
    inputs:
      command: 'push'
      packagesToPush: ${{ parameters.packagePath }}
      nuGetFeedType: 'internal'
      publishVstsFeed: 'HoneyDrunk/${{ parameters.feedName }}'
      allowPackageConflicts: false

And to avoid brittle GUIDs, this script dynamically builds the feed URL:

- script: |
    FEED_URL="https://pkgs.dev.azure.com/$(System.TeamFoundationCollectionUri | sed 's|https://dev.azure.com/||')/_packaging/${{ parameters.feedName }}/nuget/v3/index.json"
    echo "##vso[task.setvariable variable=FeedUrl]$FEED_URL"
  displayName: 'Compute Feed URL'

No more copy-paste errors, no more mismatched feed identifiers.

🧰 Troubleshooting & Lessons Learned
Permission Setup

Ensure your Azure Pipelines build identity (Project Build Service) has Contributor access to the feed.
Without it, pushes will silently fail.

Service Connections

Use NuGetAuthenticate@1 instead of personal PATs wherever possible — it leverages the build service identity.

Parameterization

Anything that can change — paths, feed names, versions — should be a parameter.
Hardcoded values are time bombs.

🚀 The Impact

✅ Shared templates mean all projects follow the same structure
✅ Versioning and naming stay consistent
✅ Permission errors are practically gone
✅ Onboarding a new project takes minutes

⚖️ Before vs After

Before

Copy-paste massive YAML files

Search & replace project names

Debug GUIDs and PATs by trial and error

After

Reference templates

Set parameters

Push → it just works

🐝 Why It Matters for Small Teams

For indie devs or small studios like mine:

Time is precious. Every failed build costs momentum

Context switching is brutal. You shouldn’t be debugging YAML daily

Future-you will forget. Document it once, reuse forever

Treating pipelines as infrastructure is how you scale solo work.

🔮 Next Steps

Auto-generate release notes from commits

Add semantic versioning via conventional commits

Extend templates to handle multiple languages and deployment targets

Build once. Reuse forever.
That’s how HoneyDrunk Studios automates the grid.

🧱 Originally published on TattedDev.com

Avoiding the 'Common' Trap: How I Structure Shared Packages at HoneyDrunk

Tatted Dev — Wed, 01 Oct 2025 20:48:59 +0000

When you’re building something big, it’s easy to fall into the “just toss it into Common” trap.

You know the one — a giant “Shared” library where every random helper, DTO, and extension method ends up living rent-free.

That’s fine until you wake up one day and realize you’ve created a god-class library that nobody understands and everybody hates.

I didn’t want that. HoneyDrunk (my indie dev playground) is meant to scale cleanly, so I sat down and mapped out what the shared package ecosystem should actually look like.

This post is me brain-dumping how I’m structuring it, so future-me doesn’t scream at past-me later.

Core First, Junk Drawer Never

The heart of the platform starts with fundamentals:

HoneyDrunk.Core → base entities, domain events, common exceptions
HoneyDrunk.Validation → validators and rule sets
HoneyDrunk.Security → Argon2 hashing, JWT utilities, auth helpers
HoneyDrunk.Caching → Redis + memory abstractions
HoneyDrunk.Configuration → Key Vault + strongly typed configs
HoneyDrunk.FeatureFlags → clean feature toggles

These are primitives, not business logic. They’re the Lego bricks everything else is built on.

Data + Networking

HoneyDrunk.Data → EF Core patterns, DbContext helpers, migrations
HoneyDrunk.Storage → blob/S3/local filesystem abstraction
HoneyDrunk.Http → resilient HttpClient factory (retry, jitter, circuit breaker)
HoneyDrunk.RestService → less boilerplate over Http
HoneyDrunk.Grpc → shared contracts + helpers
HoneyDrunk.SignalR → hub contracts + client utilities

Messaging vs Notifications

Here’s where people mess it up. Messaging ≠ Notifications.

HoneyDrunk.Messaging → system-to-system (pub/sub, service bus commands)
HoneyDrunk.Notifications.Email → user-facing email
HoneyDrunk.Notifications.Sms → text messages
HoneyDrunk.Notifications.Push → mobile + web push

👉 One is about services talking to each other. The other is about talking to humans. Don’t cross the streams.

Observability + Quality

If you’re not measuring, you’re guessing.

HoneyDrunk.Observability → Serilog, OpenTelemetry, metrics, tracing
HoneyDrunk.Testing → Moq setups, Cypress helpers, fixtures, test utilities

Commerce (Not Just Payments)

I almost made a HoneyDrunk.Payments package. Glad I stopped. Payments are just one part of a bigger story.

Instead:

HoneyDrunk.Commerce.Orders
HoneyDrunk.Commerce.Payments
HoneyDrunk.Commerce.Billing

That way I can handle orders, invoices, and subscriptions without bending a “Payments” package into something it was never meant to be. Abstraction matters.

Integrations

These are where the fun APIs live:

HoneyDrunk.Integrations.Streaming → Twitch, YouTube, Kick
HoneyDrunk.Integrations.Media → AniList, TMDB
HoneyDrunk.Integrations.GamingPlatforms → Steam, Epic, Xbox APIs
HoneyDrunk.Integrations.Social → Discord, Twitter/X, Reddit

Tooling + SDKs

Ops and client devs need love too:

HoneyDrunk.Tooling.DevOps → DACPAC utilities, pipeline helpers, infra scripts
HoneyDrunk.Sdk.DotNet → SDK for .NET consumers
HoneyDrunk.Sdk.JavaScript (future) → Next.js + Expo SDKs

Satellite Sites (The Consumers)

All these packages? They’re not the product. They’re the engine room.

The actual user-facing pieces are the satellites:

Next.js → public front door
Expo mobile app → push notifications + community nudges
Blazor admin → manage users, payments, bugs
Astro marketing site → blog, docs, branding hub

🚫 Rule #1: satellites don’t talk to databases. They hit APIs/SDKs only.

Wrapping It Up

Every package name is a bet on the future.

Go too narrow and you box yourself in. Go too vague and you build a junk drawer.

HoneyDrunk is my shot at doing it the right way: explicit names, clear boundaries, and room to grow without rewriting half the platform.

Abstractions aren’t academic — they’re strategy.

And if I screw it up, future-me will definitely roast past-me for it.

Originally published at: https://www.tatteddev.com/blog/abstractions-packages-and-satellite-sites/

Forem: Tatted Dev

🍯 Announcing HoneyDrunk.Data: A Multi-Tenant Persistence Layer for Distributed .NET Applications

The Problem We're Solving

Architecture: Layers That Actually Make Sense

Feature Highlight: Correlation Tracking in SQL

Multi-Tenancy: From HTTP Header to Database Query

The Repository Pattern, Done Right

Testing Without Docker: SQLite In-Memory

SQL Server Specifics: datetime2 and Retry Logic

Getting Started

What's Next?

Links

HoneyDrunk.Transport: A Transport Agnostic Messaging Framework for .NET

What It Is

Why It Exists

1. Swap transports without rewriting code

2. Distributed context propagation

3. Middleware pipeline

4. Configurable error handling

Architecture at a Glance

Transport Adapters

Azure Service Bus

Azure Storage Queue

InMemory Transport

Try It Out

Final Notes

Honeypunk: A Semantic, Palette-Driven Theme Pipeline for Visual Studio 2026

Why Manual Theme Editing Fails

The Pipeline Model

Palette

Roles

Mappings

Build Scripts

VSIX

Core Files

Honeypunk.yaml

palette.md

roles.yaml

mappings.yaml

apply_palette.py

build_vsix.py

Palette Philosophy

Background tier

Text tier

Accent tier

Diagnostic triad

Updating for Visual Studio 2026

Extending the System

Adding a new role

Adding a new color

Multiple theme variants

Coming soon

Troubleshooting

Try It Yourself

Building a Zero-Configuration .NET Standards Package

The Problem With Code Standards

How It Works

1. Build-Transitive Package Design

2. Continuous Integration Awareness

3. Opt-Out Instead of Opt-In

Why This Approach Works

Consistent Code Quality

Configuration Centralization

Faster Onboarding

Deterministic and Auditable Builds

Common Gotchas and Solutions

1. Large Warning Backlogs

2. Missing PrivateAssets="all"

3. Test Method Naming (CA1707)

4. Overuse of the Null-Forgiving Operator (!)

5. Local vs CI Output Differences

6. Team Preference Conflicts

Implementation Best Practices

Key Takeaways

Try It Yourself

HoneyDrunk.Pipelines — Treat Your CI/CD as Infrastructure

🧠 The Problem: Pipeline Sprawl & Runtime Breakage

⚙️ The Vision: Pipelines as Reusable Infrastructure

🗂️ Repository Layout (Simplified)

Avoiding the 'Common' Trap: How I Structure Shared Packages at HoneyDrunk

2. Missing `PrivateAssets="all"`

4. Overuse of the Null-Forgiving Operator (`!`)