DEV Community: JF Meyers

I Benchmarked 3 Ways to Log in .NET : One Allocates Nothing

JF Meyers — Fri, 03 Apr 2026 10:12:20 +0000

Your API handles 2,000 requests per second. Each request logs 5 messages. That is 10,000 log calls per second — and if your log level is set to Warning, every single Debug and Information call is wasted work. The string gets built. The arguments get boxed. The GC collects the result. Nobody reads it.

I ran the benchmarks. The difference is not subtle.

Three ways to log the same thing

Here is the same log statement written three ways. All three produce identical output when the level is enabled.

// Style 1: string interpolation
logger.LogInformation($"Order {orderId} shipped to {country}");

// Style 2: message template (structured)
logger.LogInformation("Order {OrderId} shipped to {Country}", orderId, country);

// Style 3: [LoggerMessage] source generation
LogOrderShipped(orderId, country);

[LoggerMessage(Level = LogLevel.Information,
    Message = "Order {OrderId} shipped to {Country}")]
private partial void LogOrderShipped(Guid orderId, string country);

Style 1 is what most developers write by default. Style 2 is what the docs recommend. Style 3 is what the runtime team actually uses internally.

The benchmark

I used BenchmarkDotNet to measure all three styles under two conditions: when the log level is enabled (the message reaches the sink) and when it is disabled (the message is filtered out before writing).

[MemoryDiagnoser]
[ShortRunJob]
public class LoggingBenchmarks
{
    private ILogger<LoggingBenchmarks> _enabledLogger = null!;
    private ILogger<LoggingBenchmarks> _disabledLogger = null!;
    private Guid _orderId;
    private string _country = null!;

    [GlobalSetup]
    public void Setup()
    {
        _orderId = Guid.NewGuid();
        _country = "Belgium";

        _enabledLogger = LoggerFactory
            .Create(b => b.SetMinimumLevel(LogLevel.Trace).AddFakeLogger())
            .CreateLogger<LoggingBenchmarks>();

        _disabledLogger = LoggerFactory
            .Create(b => b.SetMinimumLevel(LogLevel.Warning).AddFakeLogger())
            .CreateLogger<LoggingBenchmarks>();
    }

    [Benchmark(Baseline = true)]
    public void Interpolation_Enabled()
        => _enabledLogger.LogInformation($"Order {_orderId} shipped to {_country}");

    [Benchmark]
    public void Template_Enabled()
        => _enabledLogger.LogInformation("Order {OrderId} shipped to {Country}",
            _orderId, _country);

    [Benchmark]
    public void SourceGen_Enabled()
        => LogOrderShipped(_enabledLogger, _orderId, _country);

    [Benchmark]
    public void Interpolation_Disabled()
        => _disabledLogger.LogInformation($"Order {_orderId} shipped to {_country}");

    [Benchmark]
    public void Template_Disabled()
        => _disabledLogger.LogInformation("Order {OrderId} shipped to {Country}",
            _orderId, _country);

    [Benchmark]
    public void SourceGen_Disabled()
        => LogOrderShipped(_disabledLogger, _orderId, _country);

    [LoggerMessage(Level = LogLevel.Information,
        Message = "Order {OrderId} shipped to {Country}")]
    private static partial void LogOrderShipped(
        ILogger logger, Guid orderId, string country);
}

Results (.NET 10, x64, RyuJIT)

Method	Mean	Allocated
Interpolation_Enabled	~320 ns	256 B
Template_Enabled	~280 ns	64 B
SourceGen_Enabled	~250 ns	0 B
Interpolation_Disabled	~95 ns	184 B
Template_Disabled	~35 ns	64 B
SourceGen_Disabled	~1.5 ns	0 B

Read that last row again. 1.5 nanoseconds. Zero bytes allocated. When the level is disabled, the source-generated method checks IsEnabled and returns immediately — no string formatting, no boxing, no array allocation. The interpolation version still burns 95 ns building a string that nobody will ever see.

At 10,000 calls/second with the level disabled, that is:

Interpolation: 1.8 MB/s of garbage for the GC to collect
Message template: 640 KB/s of garbage
Source generation: nothing

Why the difference exists

String interpolation (`$"..."`)

The compiler transforms $"Order {orderId} shipped to {country}" into a string.Format call (or DefaultInterpolatedStringHandler on .NET 6+). Either way, the string is fully constructed before LogInformation is called. The logger has no chance to skip it.

// What the compiler actually generates (simplified)
var handler = new DefaultInterpolatedStringHandler(21, 2);
handler.AppendLiteral("Order ");
handler.AppendFormatted(orderId);
handler.AppendLiteral(" shipped to ");
handler.AppendFormatted(country);
logger.LogInformation(handler.ToStringAndClear()); // Already a string. Too late.

Message template (`"Order {OrderId}"`)

The ILogger extension methods accept params object?[] arguments. Value types like Guid get boxed. The object[] is allocated on every call. The level check happens inside the method — after the caller has already paid for the array.

// What you write
logger.LogInformation("Order {OrderId} shipped to {Country}", orderId, country);

// What happens at the call site
var args = new object[] { orderId, country }; // boxed Guid + array alloc
logger.Log(LogLevel.Information, "Order {OrderId} shipped to {Country}", args);
// IsEnabled check is INSIDE Log() — too late to avoid the allocation

Source generation (`[LoggerMessage]`)

The source generator emits a method that checks IsEnabled before touching any argument:

// What the source generator emits (simplified)
private static void LogOrderShipped(ILogger logger, Guid orderId, string country)
{
    if (!logger.IsEnabled(LogLevel.Information))
        return; // Zero work done

    logger.Log(
        LogLevel.Information,
        new EventId(0, nameof(LogOrderShipped)),
        new __LogOrderShippedStruct(orderId, country), // stack-allocated struct
        null,
        __LogOrderShippedStruct.Format);
}

The arguments are passed to a generated struct — no heap allocation, no boxing. The format method is cached as a static delegate. When the level is disabled, the method returns in a single branch instruction.

Five things I got wrong the first time

When I migrated a codebase to [LoggerMessage], I hit every possible mistake. Saving you the trip:

1. Forgetting partial on the class

The method is partial, but so must be the containing class. The source generator needs to emit the implementation in a separate file.

// Compiler error: no suitable method found to override
public class OrderService { ... }

// Works
public partial class OrderService { ... }

2. Using interpolation inside the message string

The Message property is a template, not a format string. Placeholders use {PascalCase} names that match the method parameters.

// Wrong — this is a constant string, not a template
[LoggerMessage(Level = LogLevel.Information,
    Message = $"Order {nameof(orderId)} processed")] // Compile error

// Right — named placeholders matching parameters
[LoggerMessage(Level = LogLevel.Information,
    Message = "Order {OrderId} processed")]
private partial void LogOrderProcessed(Guid orderId);

3. Returning a value from a log method

[LoggerMessage] methods must return void. They are fire-and-forget by design.

4. Mismatching parameter names and placeholders

The parameter name orderId maps to the placeholder {OrderId} by convention (case-insensitive). If they do not match, the generator emits a warning and the value shows as (null) in output.

5. Forgetting the Exception parameter

If your message accompanies an error, pass the Exception as a parameter — do not .ToString() it into the message. The logging infrastructure preserves the full exception object, and sinks like Seq or Application Insights render it properly.

// Wrong — stack trace baked into a string, impossible to filter
[LoggerMessage(Level = LogLevel.Error,
    Message = "Import failed: {Error}")]
private partial void LogImportFailed(string error);
// Called as: LogImportFailed(ex.ToString()); 

// Right — exception is structured metadata
[LoggerMessage(Level = LogLevel.Error,
    Message = "Import failed for job {JobId}")]
private partial void LogImportFailed(Guid jobId, Exception exception);

When to use each style

I am not saying you should grep-and-replace every logger.Log* call in your codebase tomorrow. Here is a practical decision framework:

Context	Recommendation	Why
Hot paths (>100 calls/s)	`[LoggerMessage]`	Zero allocation matters here
Library code (NuGet packages)	`[LoggerMessage]`	You do not control the consumer's log level
Application startup / shutdown	Message template is fine	Runs once, readability wins
Quick prototype / script	Interpolation is fine	You are not shipping this
Anywhere you log an `Exception`	`[LoggerMessage]`	Structured exception > `.ToString()`

The real decision point: if the code runs in a loop or on every request, use [LoggerMessage]. For everything else, message templates are a reasonable default.

Migration in 10 minutes

Here is a quick mechanical process for an existing class:

- public class PaymentService
+ public partial class PaymentService
  {
      private readonly ILogger<PaymentService> _logger;

      public async Task ChargeAsync(Guid paymentId, decimal amount)
      {
-         _logger.LogInformation($"Charging {amount:C} for payment {paymentId}");
+         LogCharging(paymentId, amount);
          // ...
-         _logger.LogError(ex, $"Payment {paymentId} failed");
+         LogChargeFailed(paymentId, ex);
      }
+
+     [LoggerMessage(Level = LogLevel.Information,
+         Message = "Charging {Amount} for payment {PaymentId}")]
+     private partial void LogCharging(Guid paymentId, decimal amount);
+
+     [LoggerMessage(Level = LogLevel.Error,
+         Message = "Payment {PaymentId} failed")]
+     private partial void LogChargeFailed(Guid paymentId, Exception exception);
  }

Steps:

Add partial to the class declaration
For each logger.Log*() call, create a [LoggerMessage] partial method
Replace the call site with the new method
Build — the generator validates signatures at compile time

If you have a large codebase, the Microsoft.Extensions.Logging analyzer (SYSLIB1006-SYSLIB1015) flags common issues. Enable it in your .editorconfig:

[*.cs]
dotnet_diagnostic.SYSLIB1006.severity = warning

The compliance bonus nobody talks about

Here is a side benefit that surprised me: [LoggerMessage] makes GDPR compliance audits easier.

With string interpolation, PII can hide anywhere: $"User {email} logged in" bakes the email into an opaque string. You cannot redact it downstream. Your only option is a regex-based log scrubber — fragile and always one edge case away from leaking data.

With [LoggerMessage], every parameter is explicitly named in the attribute. You can write a Roslyn analyzer that scans all [LoggerMessage] declarations and flags any placeholder named Email, Phone, IpAddress, or Token at build time. PII never reaches production logs because the compiler stops you.

I built exactly this for Granit, an open-source modular .NET framework I maintain. The analyzer (GRSEC011) flags PII-indicative parameter names, and architecture tests verify every [LoggerMessage] across 120+ packages. Zero PII in logs, enforced at compile time — not by policy documents that nobody reads.

TL;DR

String interpolation in logs allocates on every call, even when the level is disabled. At scale, that is measurable GC pressure.
Message templates avoid the string but still box value types into object[].
[LoggerMessage] source generation checks the level first, avoids all allocation, and preserves structured data.
The difference is 1.5 ns vs 95 ns when the level is disabled. At scale, that is free GC pressure you are handing back to your application.
Migration is mechanical: add partial, extract methods, build. The compiler does the rest.
Bonus: named parameters make PII audits trivial — a Roslyn analyzer can enforce data minimization at compile time.

I maintain Granit, an open-source modular .NET framework (200+ NuGet packages, Apache-2.0) with built-in GDPR compliance, isolated DbContexts, and source-generated everything. If you are building enterprise .NET apps and tired of reinventing the same plumbing, check it out.

RoslynLens: Give Your AI Assistant Semantic Eyes on .NET Code

JF Meyers — Wed, 01 Apr 2026 07:53:06 +0000

Reading a 1,500-line C# file to find one method signature wastes tokens, time, and money. RoslynLens is an open-source MCP server that gives AI coding assistants like Claude Code direct access to Roslyn semantic analysis — so they can query your .NET codebase the way an IDE does, not the way grep does.

One MCP call. 30-150 tokens. No file reading required.

The problem: AI assistants are blind navigators

When Claude Code (or any AI assistant) works with a .NET codebase, it has two options to understand your code:

Read entire files — 500 to 2,000+ tokens per .cs file, most of which is irrelevant noise
Grep and hope — text-based search that can't distinguish a type name from a variable, a declaration from a usage

Neither approach understands your code. They process text. They miss inheritance hierarchies, cross-project references, interface implementations, and semantic relationships.

The result? Wasted context window, missed connections, and wrong assumptions.

The solution: semantic queries via MCP

RoslynLens loads your .NET solution into a Roslyn MSBuildWorkspace and exposes 28 tools through the Model Context Protocol. Instead of reading files, the AI assistant sends focused queries and gets back structured, minimal responses.

Before RoslynLens — finding who calls OrderService.SubmitAsync:

1. Grep for "SubmitAsync" across 200 files -> 47 matches (including comments, strings, other methods)
2. Read 12 files to narrow down -> ~15,000 tokens consumed
3. Still not sure about indirect calls through interfaces

After RoslynLens — same task:

find_callers("OrderService.SubmitAsync")
-> 4 callers with file, line, containing method — 85 tokens

Quick start

Install as a global .NET tool:

dotnet tool install --global RoslynLens

claude mcp add --scope user --transport stdio roslyn-lens -- roslyn-lens

That's it. RoslynLens auto-discovers the nearest .sln or .slnx file (BFS, max 3 levels), loads it in the background, and starts serving queries over stdio.

You can also configure it via .mcp.json in your project root:

{
  "mcpServers": {
    "roslyn-lens": {
      "type": "stdio",
      "command": "roslyn-lens",
      "args": []
    }
  }
}

28 tools at a glance

RoslynLens tools fall into six categories.

Symbol navigation

Tool	What it does
`find_symbol`	Locate definitions by name — supports glob patterns (`Service`, `GetUser`)
`find_references`	All usages of a symbol across the solution
`find_implementations`	Interface implementors and derived classes
`find_callers`	Direct callers of a method
`find_overrides`	Overrides of virtual/abstract methods
`find_dead_code`	Unused types, methods, properties — with filters for public members, entry points, project/file scope

Inspection

Tool	What it does
`get_public_api`	Public surface of a type — no file reading
`get_symbol_detail`	Full signature, parameters, return type, XML docs
`get_type_hierarchy`	Inheritance chain, interfaces, derived types
`get_project_graph`	Solution dependency tree (with `projectFilter` for large solutions)
`get_dependency_graph`	Method call chain visualization
`get_diagnostics`	Compiler warnings and errors
`get_test_coverage_map`	Heuristic test-to-code mapping

Analysis

Tool	What it does
`get_complexity_metrics`	Cyclomatic, cognitive complexity, nesting depth, LOC
`analyze_data_flow`	Variable assignments, reads, writes, captured variables
`analyze_control_flow`	Reachability, return points, exit points
`detect_antipatterns`	18 built-in detectors (see below)
`detect_circular_dependencies`	Project and type-level cycle detection
`detect_duplicates`	Structurally similar code via AST fingerprinting

Compound tools (one call, multiple analyses)

Tool	What it does
`analyze_method`	Signature + callers + dependencies + complexity in one call
`get_type_overview`	Public API + hierarchy + implementations + diagnostics
`get_file_overview`	Types + diagnostics + anti-patterns for a file

Batch operations (multiple symbols, one call)

Tool	What it does
`find_symbols_batch`	Resolve multiple symbol names at once
`get_public_api_batch`	Public API of multiple types at once
`get_symbol_detail_batch`	Details of multiple symbols at once

External & specialized

Tool	What it does
`resolve_external_source`	Resolve NuGet/framework source via SourceLink or decompilation
`get_module_depends_on`	`[DependsOn]` attribute graph for modular monoliths
`validate_conventions`	Convention violation checker

18 anti-pattern detectors

RoslynLens doesn't just navigate code — it catches common .NET mistakes at query time. Detectors run on syntax trees with optional semantic model analysis, so they're fast and don't require a full compilation for basic checks.

General .NET

ID	What it catches
AP001	`async void` methods (except event handlers)
AP002	Sync-over-async: `.Result`, `.Wait()`, `.GetAwaiter().GetResult()`
AP003	`new HttpClient()` instead of `IHttpClientFactory`
AP004	`DateTime.Now`/`UtcNow` instead of `TimeProvider`
AP005	`catch (Exception)` without re-throw
AP006	String interpolation in log calls (structured logging violation)
AP007	`#pragma warning disable` without matching `restore`
AP008	Async methods missing `CancellationToken` parameter
AP009	EF Core queries without `.AsNoTracking()`

Domain-specific

ID	What it catches
GR-GUID	`Guid.NewGuid()` instead of `IGuidGenerator`
GR-SECRET	Hardcoded passwords, connection strings, API keys
GR-SYNC-EF	`SaveChanges()` instead of `SaveChangesAsync()`
GR-BADREQ	`TypedResults.BadRequest<string>()` instead of `Problem()`
GR-REGEX	`new Regex()` instead of `[GeneratedRegex]`
GR-SLEEP	`Thread.Sleep()` in production code
GR-CONSOLE	`Console.Write`/`WriteLine` instead of `ILogger`
GR-CFGAWAIT	Missing `ConfigureAwait(false)` in library code
GR-DTO	Classes/records with `*Dto` suffix (naming convention violation)

Adding a new detector is straightforward. For simple invocation matches (Foo.Bar()), extend InvocationDetectorBase. For new Foo() patterns, extend ObjectCreationDetectorBase. For complex logic, implement IAntiPatternDetector directly.

Deep dive: key v1.1 features

Fuzzy FQN resolution

AI assistants often send imprecise symbol names. Instead of failing, RoslynLens uses a three-tier fallback strategy:

Exact match — case-insensitive, highest priority
Partial namespace — MyService resolves to MyApp.Services.MyService
Levenshtein distance — typo tolerance (1-2 edits depending on name length)

When multiple candidates match, the response includes a disambiguation list with fully qualified names, file paths, and line numbers — so the AI can pick the right one without another round-trip.

Duplicate code detection via AST fingerprinting

Text-based diff tools miss renamed-but-identical logic. RoslynLens normalizes syntax trees by replacing identifiers with ID, literals with LIT, and types with TYPE, then computes a SHA256 fingerprint of the normalized structure. Methods with identical fingerprints are structurally equivalent — regardless of variable names.

detect_duplicates(projectFilter: "MyProject", minStatements: 5)
-> 3 duplicate groups, each with locations + similarity score

Complexity metrics (SonarSource model)

get_complexity_metrics computes four metrics per method:

Cyclomatic complexity — counts decision points (if, while, for, switch, catch, &&, ||, ??)
Cognitive complexity — SonarSource model with nesting penalties
Nesting depth — maximum block nesting level
Logical LOC — excluding blanks and comments

Supports method, type, and project scope with a configurable threshold to surface only the worst hotspots.

Data flow and control flow analysis

Built on Roslyn's SemanticModel.AnalyzeDataFlow() and AnalyzeControlFlow():

Data flow: variables declared, read inside, written inside, always assigned, captured by closures
Control flow: start/end reachability, return statement count, exit points

External source resolution

When the AI needs to understand a NuGet package API, RoslynLens follows a resolution hierarchy:

SourceLink — check if the symbol has source locations in the solution
Decompilation — fallback via ICSharpCode.Decompiler (truncated to 60 lines for token efficiency)

No more telling the AI to "just check the NuGet documentation."

Architecture: designed for large solutions

RoslynLens is built to handle real-world .NET solutions with 50+ projects:

Background loading — the solution loads asynchronously via a BackgroundService. Tools return a "loading" status until the workspace is ready, then serve queries instantly.
Lazy compilation with LRU cache — solutions with many projects compile on-demand. A configurable LRU cache (default: 20 compilations) keeps frequently accessed projects hot.
File watchers — .cs changes trigger incremental text updates on the Roslyn workspace. .csproj changes trigger a full reload. No restart needed.
Logs to stderr — stdout is reserved for JSON-RPC (MCP protocol). All diagnostic output goes to stderr.

src/RoslynLens/
├── Program.cs                  # Host + MCP stdio transport
├── SolutionDiscovery.cs        # BFS .sln/.slnx auto-discovery
├── WorkspaceManager.cs         # MSBuildWorkspace, LRU compilation cache
├── WorkspaceInitializer.cs     # Background solution loading
├── SymbolResolver.cs           # Cross-project resolution + fuzzy FQN
├── ComplexityAnalyzer.cs       # Cyclomatic/cognitive complexity
├── DuplicateCodeDetector.cs    # AST fingerprinting
├── ExternalSourceResolver.cs   # SourceLink + decompilation
├── Tools/                      # 28 MCP tool implementations
├── Analyzers/                  # 18 anti-pattern detectors
└── Responses/                  # Token-optimized DTOs

Configuration

Four environment variables for runtime tuning:

Variable	Default	Purpose
`ROSLYN_LENS_TIMEOUT_SECONDS`	30	Operation timeout
`ROSLYN_LENS_MAX_RESULTS`	100	Maximum results per query
`ROSLYN_LENS_CACHE_SIZE`	20	LRU compilation cache size
`ROSLYN_LENS_LOG_LEVEL`	Information	Log verbosity

Real-world impact: token savings

Here's a comparison on a 35-project solution (~180,000 lines of C#):

Task	Without RoslynLens	With RoslynLens	Savings
Find all implementations of `IRepository`	Read 8 files (~12,000 tokens)	`find_implementations` (95 tokens)	99%
Understand `OrderService` API	Read full file (1,800 tokens)	`get_public_api` (120 tokens)	93%
Check for anti-patterns in a module	Read 15 files (~22,000 tokens)	`detect_antipatterns` (200 tokens)	99%
Analyze complexity hotspots	Manual review across projects	`get_complexity_metrics` (150 tokens)	N/A (not feasible manually)

The compound tools push this further. analyze_method replaces what would be 4-5 separate tool calls (or 4-5 file reads) with a single query.

Key takeaways

RoslynLens replaces file reading with semantic queries — 30-150 tokens instead of 500-2,000+ per file
28 tools cover navigation, analysis, batch operations, and compound queries
18 anti-pattern detectors catch common .NET mistakes at query time
Fuzzy FQN resolution handles imprecise AI queries gracefully
AST-based duplicate detection finds renamed-but-identical logic
Works on large solutions — lazy compilation, LRU cache, background loading

Get started

# Install
dotnet tool install --global RoslynLens

# Register with Claude Code
claude mcp add --scope user --transport stdio roslyn-lens -- roslyn-lens

# Done. Navigate to any .NET project and Claude Code can query it.

GitHub: jfmeyers/roslyn-lens | NuGet: RoslynLens | License: Apache-2.0

Built by JF Meyers. Contributions welcome.

Your Enterprise Customer Just Asked for a SOC 2 Type 2 Report. Now What?

JF Meyers — Sat, 28 Mar 2026 11:27:17 +0000

You are three weeks from closing a six-figure deal. The customer's security team sends a vendor assessment form. Question 4: "Do you have a SOC 2 Type 2 report?"

You don't.

The deal goes on hold. Six months later, it dies.

This is happening more and more. SOC 2 Type 2 is no longer just a nice-to-have for companies selling to US enterprise — it is a procurement gate. And for .NET teams, the path from "we should probably do this" to "we have the controls in place" is less obvious than it should be.

This article maps the five SOC 2 Trust Service Criteria (TSC) to concrete .NET controls, and shows how Granit — an open-source modular .NET 10 framework — covers most of the technical side out of the box.

SOC 2 in one paragraph

SOC 2 is an AICPA standard. It comes in two flavors:

Type 1: your controls exist at a point in time. Cheap to get. Low customer value.
Type 2: your controls operated effectively over a 6–12 month observation window. Expensive. What enterprise customers actually want.

The audit covers up to five Trust Service Criteria. Only Security (CC) is mandatory. Most enterprise customers also require Availability and Confidentiality.

The key thing to internalize: the auditor does not certify your code. They certify that your controls operated and that your team followed procedures. Granit gives you the technical controls. The processes, runbooks, and evidence collection are still on you.

CC6 — Logical access controls

This is the biggest control family. It covers authentication, authorization, and how you prevent unauthorized access.

CC6.1 — Strong authentication

Granit's BFF module keeps tokens off the browser entirely. The access_token and refresh_token live server-side in an encrypted HttpOnly, SameSite=Strict session cookie. No XSS attack — including a compromised npm dependency — can steal a token the browser never had.

// Program.cs
builder.AddGranit(granit => granit
    .AddModule<GranitBffModule>()
    .AddModule<GranitBffYarpModule>());

For machine-to-machine flows, Granit.Authentication.DPoP implements RFC 9449 proof-of-possession tokens. Even if an attacker intercepts an access token, they cannot replay it without the client's private key.

The full FAPI 2.0 security profile — PKCE (RFC 7636) + PAR (RFC 9126) + DPoP (RFC 9449) + private_key_jwt (RFC 7523) — is available via Granit.OpenIddict.

CC6.3 — Authorization and least-privilege

Granit.Authorization stores permissions in the database and evaluates them at runtime. No recompile cycle when your access model changes. Permissions follow a strict [Group].[Resource].[Action] format enforced by architecture tests.

// Endpoint declaration
group.MapDelete("/{id:guid}", DeleteAsync)
    .RequirePermission(InvoicePermissions.Invoices.Manage);

Per-tenant permission policies are built-in via Granit.MultiTenancy — the same endpoint can enforce different access rules for different customer organizations.

CC6.7 — Encryption at rest

Granit.Encryption provides IStringEncryptionService for field-level encryption. In development, it falls back to AES-256-CBC automatically. In production, Granit.Vault.HashiCorp delegates to HashiCorp Vault Transit — the key never leaves Vault:

public class PatientService(IStringEncryptionService encryption)
{
    public async Task<Patient> CreateAsync(
        string name,
        string nationalId,
        CancellationToken ct)
    {
        // nationalId is encrypted before it touches the database
        string encrypted = await encryption.EncryptAsync(nationalId, ct)
            .ConfigureAwait(false);

        return Patient.Create(name, encrypted);
    }
}

The Vault module disables itself in Development — no local Vault instance needed for day-to-day development.

CC6.8 — Malware and supply chain

See the BFF section above. Tokens never in localStorage. Supply chain XSS attacks are neutralized by design, not by CSP headers.

CC7 — System operations and monitoring

CC7.1 — Anomaly detection

Granit.Observability wires Serilog + OpenTelemetry in one module registration:

builder.AddGranit(granit => granit
    .AddModule<GranitObservabilityModule>());

Every module emits:

Structured logs via [LoggerMessage] source generation — no string interpolation, no accidental PII in log output
Metrics via IMeterFactory — standardized naming (granit.authorization.permission.check, granit.persistence.query.duration)
Distributed traces via ActivitySource — one per module, correlated with logs via trace_id

The Grafana LGTM stack (Loki + Grafana + Tempo + Mimir) ships as a Docker Compose overlay. A trace_id on every request means you can reconstruct the exact sequence of events for any incident — which is what the auditor wants to see.

CC7.2 — Audit trail

This is the one control teams most often try to implement manually and get wrong. With Granit, it is automatic:

// Inheriting AuditedEntity gives you these four fields on every write:
// CreatedAt  → IClock.Now (UTC, always)
// CreatedBy  → ICurrentUserService.UserId (or "system" for jobs)
// ModifiedAt → IClock.Now
// ModifiedBy → ICurrentUserService.UserId

public sealed class Invoice : FullAuditedAggregateRoot<Guid>
{
    public decimal Amount { get; private set; }

    public static Invoice Create(decimal amount) =>
        new() { Amount = amount };
    // Audit fields set by interceptor inside SaveChangesAsync — not by application code
}

AuditedEntityInterceptor runs inside the same database transaction as the business write. You cannot have a committed write without an audit record. You cannot accidentally skip it.

For business-level events ("Invoice approved by Marie"), the Timeline module adds a human-readable activity log with actor, timestamp, and Markdown body — independent of the field-level audit trail.

Confidentiality TSC — crypto-shredding

Here is a problem that comes up in every SOC 2 + GDPR scenario:

GDPR Art. 17 says you must be able to erase a user's data.
SOC 2 CC7.2 says your audit trail must be immutable.

These appear to contradict. If you delete rows to satisfy GDPR, your audit trail references records that no longer exist. If you keep the rows, you're not actually erasing the data.

Granit.Privacy resolves this with crypto-shredding:

Each tenant's sensitive fields are encrypted with a tenant-specific key stored in Vault.
On erasure request, the key is destroyed in Vault.
All encrypted fields become permanently unreadable — mathematically erased.
The audit trail rows stay intact. The data they reference is gone.

No rows deleted. Full erasure. Intact audit trail. Compliant with both.

Availability TSC

Granit.RateLimiting protects against abusive traffic patterns. Standard 429 Too Many Requests with Retry-After header — easily validated in load tests for the auditor's evidence package.

Granit.MultiTenancy supports three isolation strategies. The DatabasePerTenant strategy means one tenant's database issue cannot cascade to others — a common availability concern for SaaS audits.

Strategy	Risk containment
`SharedDatabase`	Logical (query filter)
`SchemaPerTenant`	Schema-level separation
`DatabasePerTenant`	Full physical isolation

Privacy TSC

[LoggerMessage] source generation enforces that no PII can slip into log strings at compile time. The Roslyn analyzer flags violations before they reach CI.
IProcessingRestrictable adds a global EF Core query filter for processing restriction (GDPR Art. 18) — applied by ApplyGranitConventions, never forgettable.
IPersonalDataProvider aggregates personal data exports across all modules for data portability requests (GDPR Art. 15 / SOC 2 P4.1).

What you still need to do

Granit handles the technical controls. The audit also requires:

Incident response runbook — a documented procedure, not just Grafana dashboards
Access review cadence — quarterly reviews of who has production access, with evidence
Change management — pull request policies, deployment approval gates
Employee security training — awareness + phishing simulation records
Annual penetration test — with findings and remediation tracking
Vendor due diligence — security assessments for your own third-party integrations

The observation window starts when you engage your auditor. Starting with the technical controls already in place means your preparation budget goes to the operational side — which is where the actual audit risk lives.

SOC 2 TSC compliance matrix

Criterion	Control	Granit module
CC6.1 — Authentication	JWT Bearer + DPoP + PKCE	`Granit.Authentication`
CC6.1 — Transport encryption	`RequireHttpsMetadata = true`	`Granit.Authentication`
CC6.3 — Authorization	Dynamic RBAC/ABAC, runtime permissions	`Granit.Authorization`
CC6.3 — Tenant isolation	Query filters, 3 strategies	`Granit.MultiTenancy`
CC6.6 — Third-party auth	FAPI 2.0 (PAR + DPoP + `private_key_jwt`)	`Granit.OpenIddict`
CC6.7 — Encryption at rest	Field-level AES / Vault Transit	`Granit.Encryption`, `Granit.Vault`
CC6.7 — Key management	HashiCorp Vault, auto-rotation	`Granit.Vault.HashiCorp`
CC6.8 — Token protection	BFF pattern, HttpOnly cookies	`Granit.Bff`
CC7.1 — Anomaly detection	Structured logs + metrics + traces	`Granit.Observability`
CC7.2 — Audit trail	Interceptor-based, immutable	`Granit.Auditing`
A1.1 — Availability	Rate limiting, distributed cache	`Granit.RateLimiting`, `Granit.Caching`
A1.2 — Tenant isolation	DB/schema/filter strategies	`Granit.MultiTenancy`
C1.1 — Confidentiality	Field encryption + crypto-shredding	`Granit.Encryption`, `Granit.Privacy`
P4.1 — Data portability	`IPersonalDataProvider` aggregation	`Granit.Privacy`
P8.1 — Right to erasure	Crypto-shredding via Vault key destruction	`Granit.Privacy`

TL;DR

SOC 2 Type 2 is a process audit, not a code audit. But the technical controls need to be in place and operating before the observation window starts.

If you're building on .NET, Granit gives you CC6, CC7, and the Confidentiality/Privacy TSC controls out of the box: dynamic RBAC, automatic audit trails, field-level encryption with Vault key management, BFF token protection, and crypto-shredding for GDPR erasure without breaking your audit trail.

The hard part — runbooks, access reviews, pen tests, employee training — is still on you. But starting with a framework that makes the compliant path the default path means you're spending your prep time on the right things.

Full documentation: granit-fx.dev
Source code: github.com/granit-fx/granit-dotnet (Apache 2.0)

Swashbuckle Is Dead. Here's How to Migrate to Scalar in .NET 10.

JF Meyers — Sat, 28 Mar 2026 09:57:22 +0000

Why Swashbuckle is no longer the right choice

Swashbuckle.AspNetCore was the de facto Swagger UI for .NET for years.
Today it has three problems that are hard to work around:

Problem	Impact
No OpenAPI 3.1 support	Can't use JSON Schema features (`const`, webhooks, `$ref` siblings)
Upstream archived	No security patches, no .NET compatibility updates
Bypasses native metadata	Misses `.Produces<T>()`, `.ProducesProblem()` on Minimal APIs

Microsoft removed Swashbuckle from the dotnet new webapi template in .NET 9 and
replaced it with Microsoft.AspNetCore.OpenApi. That was the official signal.

What replaced it

Two components, one stack:

Microsoft.AspNetCore.OpenApi — first-party document generator, ships with
.NET 9+. Hooks directly into the ASP.NET Core endpoint data source. No XML comment
parsing, no reflection gymnastics. Generates OpenAPI 3.1 from the metadata you
already declared.
Scalar.AspNetCore — open-source API reference portal (MIT). Reads any
OpenAPI 3.1 document and renders an interactive UI with OAuth2/PKCE auth, code
generation in 15+ languages, and a clean dark/light mode design.

They are independent. You can use the native generator with a different UI, or Scalar
with a document from NSwag. In practice, using them together is the obvious choice.

The migration — step by step

1. Remove Swashbuckle

dotnet remove package Swashbuckle.AspNetCore

Also remove any Swashbuckle.AspNetCore.* packages (annotations, filters, etc.).
Delete the AddSwaggerGen and UseSwagger / UseSwaggerUI calls from Program.cs.

2. Add the new packages

dotnet add package Microsoft.AspNetCore.OpenApi
dotnet add package Scalar.AspNetCore

3. Register document generation

using Scalar.AspNetCore;

var builder = WebApplication.CreateBuilder(args);

// Native OpenAPI document generation
builder.Services.AddOpenApi("v1", options =>
{
    options.AddDocumentTransformer((doc, _, _) =>
    {
        doc.Info = new OpenApiInfo
        {
            Title = "Bookings API",
            Version = "1.0",
            Description = "Hotel booking management API.",
        };
        return Task.CompletedTask;
    });
});

var app = builder.Build();

4. Map the endpoints

if (app.Environment.IsDevelopment())
{
    // Serves /openapi/v1.json
    app.MapOpenApi("/openapi/v1.json");

    // Serves Scalar UI at /scalar
    app.MapScalarApiReference();
}

await app.RunAsync();

That is the minimum viable setup. Navigate to /scalar and you have an interactive
API explorer backed by your live OpenAPI 3.1 document.

Adding JWT Bearer authentication

Swashbuckle had AddSecurityDefinition / AddSecurityRequirement. The native pipeline
uses document transformers.

using Microsoft.AspNetCore.Authentication;
using Microsoft.AspNetCore.OpenApi;
using Microsoft.OpenApi.Models;

internal sealed class BearerSecuritySchemeTransformer(
    IAuthenticationSchemeProvider authenticationSchemeProvider)
    : IOpenApiDocumentTransformer
{
    public async Task TransformAsync(
        OpenApiDocument document,
        OpenApiDocumentTransformerContext context,
        CancellationToken cancellationToken)
    {
        IEnumerable<AuthenticationScheme> schemes =
            await authenticationSchemeProvider.GetAllSchemesAsync();

        if (!schemes.Any(s => s.Name == "Bearer"))
        {
            return;
        }

        document.Components ??= new OpenApiComponents();
        document.Components.SecuritySchemes ??= new Dictionary<string, OpenApiSecurityScheme>();
        document.Components.SecuritySchemes["Bearer"] = new OpenApiSecurityScheme
        {
            Type = SecuritySchemeType.Http,
            Scheme = "bearer",
            BearerFormat = "JWT",
            In = ParameterLocation.Header,
            Description = "Enter your JWT token.",
        };
    }
}

builder.Services.AddTransient<BearerSecuritySchemeTransformer>();

builder.Services.AddOpenApi("v1", options =>
{
    options.AddDocumentTransformer<BearerSecuritySchemeTransformer>();
    // ...
});

Note: the transformer must be registered in DI before AddOpenApi is called,
or the DI resolution will fail at startup.

OAuth2 Authorization Code + PKCE

If your API is protected by an OAuth2 provider (Keycloak, Entra ID, Auth0), you can
configure Scalar to authenticate directly in the browser — no Postman needed.

app.MapScalarApiReference(opts =>
{
    opts.WithTitle("Bookings API");
    opts.AddAuthorizationCodeFlow("OAuth2", flow =>
    {
        flow.WithClientId("bookings-frontend-client")
            .WithSelectedScopes("openid", "profile")
            .WithPkce(Pkce.Sha256);
    });
});

Scalar shows a Sign in button. The flow runs entirely in the browser. The resulting
token is automatically attached to every test request.

Use a public (frontend) client. Never configure your backend confidential client
here — it would expose the client secret in a browser context.

Multi-version APIs

One document per major version. Each call to AddOpenApi registers an independent
document:

builder.Services.AddOpenApi("v1", options => { /* ... */ });
builder.Services.AddOpenApi("v2", options => { /* ... */ });

app.MapOpenApi("/openapi/v1.json");
app.MapOpenApi("/openapi/v2.json");

app.MapScalarApiReference(opts =>
{
    opts.WithEndpointPrefix("/scalar/{documentName}");
});

The default Scalar route (/scalar/{documentName}) handles version switching in the UI.

Common gotchas

`.Produces<T>()` is required — there is no fallback inference

Swashbuckle could sometimes infer response types by inspecting the action return type.
The native pipeline does not. If you omit .Produces<T>(), the operation has no
response schema.

// Missing .Produces<BookingResponse>() → no response type in the OpenAPI document
app.MapGet("/bookings/{id:guid}", GetBookingAsync)
    .WithName("GetBooking")
    .WithSummary("Returns a booking by ID.")
    .ProducesProblem(StatusCodes.Status404NotFound);
    // .Produces<BookingResponse>() ← you must add this

// Correct
app.MapGet("/bookings/{id:guid}", GetBookingAsync)
    .WithName("GetBooking")
    .WithSummary("Returns a booking by ID.")
    .Produces<BookingResponse>()
    .ProducesProblem(StatusCodes.Status404NotFound);

Use `TypedResults`, not `Results`

Results.Ok(value) returns IResult at compile time — the native pipeline cannot
determine the response type. TypedResults.Ok(value) returns Ok<T> — the type is
known statically and shows up in the OpenAPI schema automatically.

// BAD — type lost at compile time
return Results.Ok(booking);

// GOOD — type preserved, OpenAPI schema complete
return TypedResults.Ok(booking);

Protect the docs endpoint in non-development environments

app.MapOpenApi() and app.MapScalarApiReference() create unauthenticated endpoints
by default. In staging or production, protect them explicitly:

app.MapOpenApi("/openapi/v1.json")
   .RequireAuthorization("InternalDeveloper");

app.MapScalarApiReference()
   .RequireAuthorization("InternalDeveloper");

Or gate the entire block with IsDevelopment() and add explicit staging config.

Transformers run in registration order

Document transformers execute in the order they are registered. If transformer B
depends on data set by transformer A, register A first. This tripped me up with a
security scheme transformer that assumed doc.Components was already initialized.

Scalar vs Swagger UI — feature comparison

Feature	Swagger UI (Swashbuckle)	Scalar
OpenAPI version	2.0 / 3.0	3.1
.NET 9/10 native pipeline	No	Yes
Interactive request builder	Yes	Yes
OAuth2 PKCE in browser	Partial	Yes, first-class
Code generation	No	15+ languages
Dark mode	Third-party themes	Built-in
Maintenance status	Archived	Active (MIT)

If you use a framework that already handles this

Rolling the transformer pipeline manually gets repetitive across projects. If you work
with the open-source Granit framework for .NET, all of
this is pre-wired in the Granit.Http.ApiDocumentation module: security schemes,
OAuth2 PKCE, multi-version documents, and production protection are all configured
from a single appsettings.json section.

{
  "ApiDocumentation": {
    "Title": "Bookings API",
    "MajorVersions": [1, 2],
    "AuthorizationPolicy": "InternalDeveloper",
    "OAuth2": {
      "AuthorizationUrl": "https://auth.example.com/.../auth",
      "TokenUrl": "https://auth.example.com/.../token",
      "ClientId": "bookings-frontend-client"
    }
  }
}

Worth a look if you are building a new modular .NET backend from scratch.

Summary

The migration from Swashbuckle to Scalar on .NET 10 is straightforward once you know
the transformer pattern. The short version:

Remove Swashbuckle.AspNetCore, add Microsoft.AspNetCore.OpenApi + Scalar.AspNetCore
Replace AddSwaggerGen with AddOpenApi + document transformer for metadata
Replace UseSwagger / UseSwaggerUI with MapOpenApi + MapScalarApiReference
Switch all handlers from Results.* to TypedResults.*
Add .Produces<T>() explicitly on every endpoint
Protect the docs endpoints outside of development

The result: OpenAPI 3.1, a modern interactive UI, native OAuth2 PKCE, and no more
dependency on an archived package.

Have questions or migration tips to share? Drop them in the comments.

Let AI Agents Call Your .NET API — MCP Server in 3 Steps

JF Meyers — Thu, 26 Mar 2026 13:42:35 +0000

Your REST API already serves frontend apps, mobile clients, and third-party integrations. But when an AI agent — Claude, Copilot, Cursor — needs to interact with your application, it's stuck parsing OpenAPI specs, generating HTTP calls, and hoping the auth tokens line up.

The Model Context Protocol (MCP) changes this. An AI agent connects to your app, discovers available tools with typed parameters and descriptions, and invokes them directly. No glue code. No prompt engineering per endpoint.

In this article, I'll show how to turn any .NET module into an MCP server — with real authorization, GDPR-safe output, and multi-tenant isolation. We'll go from zero to a working MCP server in under 50 lines of code.

What is MCP?

MCP is an open protocol created by Anthropic and backed by Microsoft. Think of it as "USB-C for AI agents" — a standard way for agents to discover and invoke capabilities exposed by your application.

The flow:

Agent connects to https://your-app/mcp
Agent calls tools/list → gets a typed catalog of available tools
Agent picks the right tool based on the user's intent
Agent calls tools/call with typed parameters
Your app runs the tool, returns structured results
Agent uses the results to answer the user

User: "Show me unpaid invoices from last week"

Agent → tools/list
App   ← [SearchInvoices, GetInvoiceDetails, VoidInvoice, ...]

Agent → tools/call SearchInvoices { status: "unpaid", from: "2026-03-19" }
App   ← [{ id: 42, amount: 1250, customer: "Acme" }, ...]

Agent → User: "Found 3 unpaid invoices totaling €4,200..."

No custom API integration. No documentation parsing. The agent reads tool descriptions and decides.

The official MCP C# SDK

Microsoft and Anthropic ship the official MCP C# SDK as NuGet packages:

ModelContextProtocol — core server/client, stdio transport
ModelContextProtocol.AspNetCore — HTTP transport for ASP.NET Core

The SDK handles the protocol. You declare tools as annotated methods:

[McpServerToolType]
public static class WeatherTools
{
    [McpServerTool, Description("Gets the current weather for a city.")]
    public static string GetWeather(
        [Description("City name")] string city)
        => $"Weather in {city}: 22°C, sunny";
}

builder.Services.AddMcpServer()
    .WithHttpTransport()
    .WithToolsFromAssembly();

app.MapMcp();

That's the hello-world. But production apps need more.

What the SDK doesn't solve

When you move beyond a demo, you hit real problems:

Problem	What happens
No auth per tool	Every tool is callable by anyone who reaches the endpoint
PII in responses	`JsonSerializer.Serialize(patient)` sends email and SSN to the agent
Tool sprawl	50+ tools confuse the agent — it picks wrong ones or wastes tokens
Multi-tenancy	Tenant-specific tools show up for all tenants
Error leakage	Stack traces with connection strings reach the agent on errors
No metrics	You can't tell which tools are called, how often, or by whom

We solved all of these in Granit, an open-source modular .NET framework (Apache-2.0, 200 packages). Here's how.

Step 1: Install and register

dotnet add package Granit.Mcp.Server

// Program.cs
builder.AddGranit(granit =>
{
    granit.AddModule<GranitMcpServerModule>();
});

app.MapGranitMcpServer();

This wires up:

Streamable HTTP transport at /mcp (configurable)
SDK authorization filters — [Authorize] works on tool classes and methods
Output sanitization pipeline — PII redaction, error stripping, size limits
Tool visibility filters — tenant scope, module scope, opt-in discovery
OpenTelemetry metrics — granit.mcp.tools.invoked, request duration, active sessions
5 RBAC permissions — Mcp.Server.Access, Mcp.Tools.Execute, etc.

One call. Everything wired into the SDK's native filter pipeline — no parallel abstractions.

Step 2: Create a tool class

[McpServerToolType, McpExposed]
[Authorize(Policy = "Invoicing.Invoices.Read")]
public sealed class InvoiceMcpTools(IInvoiceReader reader)
{
    [McpServerTool, Description("Search invoices by status and date range.")]
    [McpToolOptions(ReadOnly = true)]
    public async Task<string> SearchInvoicesAsync(
        [Description("Status: draft, sent, paid, overdue")] string status,
        [Description("Start date (ISO 8601)")] DateOnly from,
        ICurrentTenant tenant,     // DI-injected, invisible to agent
        ClaimsPrincipal user,      // DI-injected, invisible to agent
        CancellationToken ct)
    {
        var invoices = await reader.SearchAsync(status, from, ct);
        return JsonSerializer.Serialize(invoices);
    }

    [McpServerTool, Description("Permanently voids an invoice.")]
    [Authorize(Policy = "Invoicing.Invoices.Manage")]
    [McpToolOptions(Destructive = true)]
    public async Task<string> VoidInvoiceAsync(
        [Description("Invoice ID")] Guid invoiceId,
        [Description("Reason for voiding")] string reason,
        CancellationToken ct)
    {
        await reader.VoidAsync(invoiceId, reason, ct);
        return $"Invoice {invoiceId} voided.";
    }
}

Key points:

[McpExposed] — opt-in discovery. In production, tools without this attribute stay hidden. Prevents accidental exposure of internal services.
[Authorize(Policy = "...")] — standard ASP.NET Core authorization. Same attribute you use on Minimal API endpoints. No custom MCP auth layer.
ICurrentTenant, ClaimsPrincipal, CancellationToken — the SDK resolves these from DI automatically. They're invisible in the tool's JSON schema — the agent never sees them.
[McpToolOptions(Destructive = true)] — MCP clients (Claude Desktop, Cursor) prompt for confirmation before invoking destructive tools.

Step 3: There is no step 3

GranitMcpModule auto-discovers all [McpServerToolType] classes from your module assemblies. No manual registration. Add a tool class to any module, deploy, and agents see it.

GDPR: PII never reaches the agent

This is the one that keeps security teams up at night. Your SearchInvoices tool returns customer data. What stops an LLM from ingesting email addresses?

The [McpRedact] attribute:

public sealed class InvoiceResponse
{
    public Guid Id { get; init; }
    public decimal Amount { get; init; }
    public string CustomerName { get; init; }

    [McpRedact(Strategy = RedactionStrategy.Omit)]
    public string CustomerEmail { get; init; }

    [McpRedact(Strategy = RedactionStrategy.Hash)]
    public string TaxId { get; init; }
}

Three strategies:

Strategy	What it does	Use for
Omit (default)	Removes the property entirely	Email, phone, address
Hash	Replaces with stable SHA-256	Correlation IDs (tax ID, SSN)
Mask	`j*@*.com`	UI-only scenarios

Why Omit is the default: masked values like j***@***.com waste LLM tokens and can trigger hallucinations — the model tries to "complete" the masked value. Omit is cleaner and safer.

The sanitization runs in the SDK's AddCallToolFilter pipeline. Every tool response passes through it before leaving your app. The ErrorSanitizer also strips stack traces and connection strings from error responses.

Multi-tenancy: tools follow the tenant

Three independent visibility filters:

1. Opt-in discovery (`[McpExposed]`)

In Explicit mode (default for production), tool classes need both [McpServerToolType] and [McpExposed]. A developer adding [McpServerTool] on an internal service for testing won't accidentally expose it.

2. Tenant scope (`[McpTenantScope]`)

[McpServerToolType, McpExposed]
[McpTenantScope(RequireTenant = true)]
public sealed class TenantReportTools(IReportService reports)
{
    // This tool only appears when a tenant context is active
}

3. Module scope (configuration)

{
  "Mcp": {
    "Server": {
      "EnabledModules": ["Invoicing", "Scheduling", "BlobStorage"]
    }
  }
}

AI agents work better with fewer, well-described tools. If your app has 30 modules, expose only the 5 that matter for the use case.

Consuming external MCP servers

The flow works both ways. Granit.Mcp.Client connects to MCP servers exposed by other services:

{
  "Mcp": {
    "Client": {
      "Connections": {
        "erp": { "Url": "https://erp.internal/mcp" },
        "analyzer": {
          "Transport": "stdio",
          "Command": "python",
          "Arguments": ["-m", "data_analyzer_mcp"]
        }
      }
    }
  }
}

IMcpClientFactory factory = sp.GetRequiredService<IMcpClientFactory>();
await using var client = await factory.CreateAsync("erp", ct);
var tools = await client.ListToolsAsync(cancellationToken: ct);

Granit.AI.Mcp bridges these into AI workspaces — external MCP tools become AITool instances in your IChatClient pipeline. A SamplingGuard prevents external servers from abusing your LLM budget (disabled by default, rate-limited when enabled).

Connect your favorite MCP client

Once deployed, connect from any MCP client:

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "my-app": {
      "type": "url",
      "url": "https://localhost:5001/mcp",
      "headers": { "Authorization": "Bearer <jwt>" }
    }
  }
}

VS Code (.vscode/mcp.json):

{
  "servers": {
    "my-app": {
      "type": "http",
      "url": "https://localhost:5001/mcp",
      "headers": { "Authorization": "Bearer <jwt>" }
    }
  }
}

What we built

4 packages, 31 tests, zero circular dependencies:

Package	What it does
`Granit.Mcp`	Auto-discovery, sanitization pipeline, OpenTelemetry metrics
`Granit.Mcp.Server`	HTTP transport, `[Authorize]` integration, RBAC permissions
`Granit.Mcp.Client`	Named factory for external MCP servers (HTTP + stdio)
`Granit.AI.Mcp`	Bridge MCP tools into IChatClient pipelines, sampling guard

Everything integrates into the SDK's native filter pipeline (AddCallToolFilter, AddListToolsFilter). No wrapper abstractions — Granit adds value only where the SDK has no opinion: authorization, sanitization, multi-tenancy, observability.

Key takeaways

MCP lets AI agents discover and invoke your tools — no custom integrations per agent
The C# SDK handles the protocol — you declare tools as annotated methods
Production needs more: auth, PII redaction, tenant isolation, error sanitization
Standard [Authorize] works on tool methods — no custom auth attributes
[McpRedact] with Omit protects PII without wasting LLM tokens
Opt-in discovery prevents accidental exposure of internal services

Granit is an open-source modular .NET 10 framework (Apache-2.0) with 200 packages covering persistence, auth, messaging, GDPR, multi-tenancy, and now MCP.

Full MCP documentation: granit-fx.dev/dotnet/mcp

Source code: [github.com/granit-fx/granit-dotnet](https://github.com/granit-fx/granit-dotnet

DEV Community: JF Meyers

I Benchmarked 3 Ways to Log in .NET : One Allocates Nothing

Three ways to log the same thing

The benchmark

Results (.NET 10, x64, RyuJIT)

Why the difference exists

String interpolation ($"...")

Message template ("Order {OrderId}")

Source generation ([LoggerMessage])

Five things I got wrong the first time

When to use each style

Migration in 10 minutes

The compliance bonus nobody talks about

TL;DR

RoslynLens: Give Your AI Assistant Semantic Eyes on .NET Code

The problem: AI assistants are blind navigators

The solution: semantic queries via MCP

Quick start

28 tools at a glance

Symbol navigation

Inspection

Analysis

Compound tools (one call, multiple analyses)

Batch operations (multiple symbols, one call)

External & specialized

18 anti-pattern detectors

General .NET

Domain-specific

Deep dive: key v1.1 features

Fuzzy FQN resolution

Duplicate code detection via AST fingerprinting

Complexity metrics (SonarSource model)

Data flow and control flow analysis

External source resolution

Architecture: designed for large solutions

Configuration

Real-world impact: token savings

Key takeaways

Get started

Your Enterprise Customer Just Asked for a SOC 2 Type 2 Report. Now What?

SOC 2 in one paragraph

CC6 — Logical access controls

CC6.1 — Strong authentication

CC6.3 — Authorization and least-privilege

CC6.7 — Encryption at rest

CC6.8 — Malware and supply chain

CC7 — System operations and monitoring

CC7.1 — Anomaly detection

CC7.2 — Audit trail

Confidentiality TSC — crypto-shredding

Availability TSC

Privacy TSC

What you still need to do

SOC 2 TSC compliance matrix

TL;DR

Swashbuckle Is Dead. Here's How to Migrate to Scalar in .NET 10.

Why Swashbuckle is no longer the right choice

What replaced it

The migration — step by step

1. Remove Swashbuckle

2. Add the new packages

3. Register document generation

4. Map the endpoints

Adding JWT Bearer authentication

OAuth2 Authorization Code + PKCE

Multi-version APIs

Common gotchas

.Produces<T>() is required — there is no fallback inference

Use TypedResults, not Results

Protect the docs endpoint in non-development environments

Transformers run in registration order

Scalar vs Swagger UI — feature comparison

If you use a framework that already handles this

Summary

Let AI Agents Call Your .NET API — MCP Server in 3 Steps

What is MCP?

The official MCP C# SDK

What the SDK doesn't solve

Step 1: Install and register

Step 2: Create a tool class

String interpolation (`$"..."`)

Message template (`"Order {OrderId}"`)

Source generation (`[LoggerMessage]`)

`.Produces<T>()` is required — there is no fallback inference

Use `TypedResults`, not `Results`

1. Opt-in discovery (`[McpExposed]`)

2. Tenant scope (`[McpTenantScope]`)