Refactoring changes internal structure without changing external behavior. Rewriting replaces implementation more broadly.
Good refactoring:
Risky refactoring:
Refactoring should reduce future cost, not create churn.
Roslyn analyzers inspect C# code at compile time.
Common analyzer categories:
Enable built-in analysis in .csproj:
<PropertyGroup>
<AnalysisLevel>latest</AnalysisLevel>
<TreatWarningsAsErrors>false</TreatWarningsAsErrors>
</PropertyGroup>
For mature projects, teams often turn selected warnings into errors.
.editorconfig keeps formatting and style consistent.
Example:
[*.cs]
dotnet_style_qualification_for_field = false:suggestion
csharp_style_namespace_declarations = file_scoped:suggestion
dotnet_diagnostic.IDE0060.severity = warning
Consistent formatting reduces review noise. Developers should discuss design, behavior, and risk instead of whitespace.
SonarQube or SonarCloud can identify:
Use static analysis as a signal, not as a substitute for engineering judgment. Not every finding has equal value, and suppressions should be intentional.
Architecture tests verify dependency rules.
Example rule:
Domain must not depend on Infrastructure.
Conceptual test:
[Fact]
public void Domain_Should_Not_Depend_On_Infrastructure()
{
var result = Types.InAssembly(typeof(Order).Assembly)
.Should()
.NotHaveDependencyOn("Store.Infrastructure")
.GetResult();
Assert.True(result.IsSuccessful);
}
Architecture tests are useful when boundaries are important and easy to accidentally violate.
A safe workflow:
For large refactors, avoid mixing:
Separate commits make review and rollback easier.
Look for:
Do not chase theoretical purity while ignoring real bugs. Code quality should support delivery and reliability.
Watch for these issues:
Sustainable code quality comes from small habits repeated consistently: clear names, focused tests, useful analyzers, architecture boundaries, and disciplined refactoring.
Next Article: Building Production-Ready .NET Systems: A Practical Roadmap
]]>The composition root is where the application wires dependencies together. In ASP.NET Core, this usually lives in Program.cs and extension methods called from it.
Example:
builder.Services.AddOrderProcessing(builder.Configuration);
builder.Services.AddPayments(builder.Configuration);
builder.Services.AddMessaging(builder.Configuration);
The goal is:
IServiceProvider calls through the codebaseKeyed services let you register multiple implementations of the same service type and choose by key.
Example:
builder.Services.AddKeyedScoped<IPaymentProcessor, StripePaymentProcessor>("stripe");
builder.Services.AddKeyedScoped<IPaymentProcessor, PaypalPaymentProcessor>("paypal");
Resolve in a minimal API:
app.MapPost("/payments/stripe", (
[FromKeyedServices("stripe")] IPaymentProcessor processor) =>
{
return processor.ProcessAsync();
});
Use keyed services when the key is a real application concept. Avoid using them to hide unclear design decisions.
A decorator wraps another implementation to add behavior.
Use cases:
Example:
public sealed class CachedProductService(
IProductService inner,
IMemoryCache cache) : IProductService
{
public Task<ProductDto?> GetByIdAsync(int id, CancellationToken cancellationToken)
{
return cache.GetOrCreateAsync(
$"products:{id}",
entry =>
{
entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5);
return inner.GetByIdAsync(id, cancellationToken);
});
}
}
Decorators keep cross-cutting behavior outside the core implementation.
Sometimes runtime values determine which implementation to use.
public sealed class PaymentProcessorFactory(IServiceProvider serviceProvider)
{
public IPaymentProcessor GetProcessor(string provider)
{
return provider switch
{
"stripe" => serviceProvider.GetRequiredKeyedService<IPaymentProcessor>("stripe"),
"paypal" => serviceProvider.GetRequiredKeyedService<IPaymentProcessor>("paypal"),
_ => throw new InvalidOperationException("Unknown payment provider.")
};
}
}
Use factories carefully. If every class starts asking the container for dependencies, you are drifting toward the service locator anti-pattern.
This is usually a smell:
public sealed class OrderService(IServiceProvider serviceProvider)
{
public Task SubmitAsync()
{
var repository = serviceProvider.GetRequiredService<IOrderRepository>();
return Task.CompletedTask;
}
}
Prefer explicit constructor dependencies. They make requirements visible and testing easier.
Watch for these issues:
IServiceProvider everywhereAdvanced DI should clarify composition, not make dependency graphs harder to understand.
Next Article: Refactoring and Code Quality in .NET: Analyzers, Sonar, Style, and Architecture Tests
]]>SignalR abstracts connection management and real-time messaging.
Core concepts:
Basic hub:
public sealed class NotificationsHub : Hub
{
public async Task JoinTenantGroup(string tenantId)
{
await Groups.AddToGroupAsync(Context.ConnectionId, $"tenant:{tenantId}");
}
}
Register and map:
builder.Services.AddSignalR();
var app = builder.Build();
app.MapHub<NotificationsHub>("/hubs/notifications");
Send from outside a hub using IHubContext.
public sealed class NotificationService(
IHubContext<NotificationsHub> hubContext)
{
public Task NotifyTenantAsync(string tenantId, string message)
{
return hubContext.Clients
.Group($"tenant:{tenantId}")
.SendAsync("notificationReceived", message);
}
}
This is useful when background jobs or API endpoints need to push updates.
Groups are essential for targeting messages.
Examples:
tenant:acmeorder:42user:123dashboard:operationsGroups are not a security boundary by themselves. You still need to authorize who can join a group.
SignalR connections can use the same ASP.NET Core authentication system.
app.MapHub<NotificationsHub>("/hubs/notifications")
.RequireAuthorization();
Inside the hub, use claims to verify access:
var tenantId = Context.User?.FindFirst("tenant_id")?.Value;
Do not let clients join arbitrary tenant or resource groups without server-side validation.
Single-instance SignalR is straightforward. Multiple app instances need a backplane or managed service so messages reach clients connected to any instance.
Common options:
For large real-time systems, prefer managed SignalR infrastructure when it fits the cloud platform. It reduces connection scaling burden.
Watch for these issues:
SignalR is best when users benefit from immediate updates. Design groups, authorization, and scale-out from the beginning.
Next Article: Advanced Dependency Injection in .NET: Keyed Services, Decorators, and Composition Roots
]]>The app needs a reliable way to determine the current tenant.
Common strategies:
acme.example.com/tenants/acme/ordersX-Tenant-Idtenant_idExample middleware concept:
public sealed class TenantMiddleware(RequestDelegate next)
{
public async Task InvokeAsync(HttpContext context, ITenantResolver resolver)
{
var tenant = await resolver.ResolveAsync(context);
if (tenant is null)
{
context.Response.StatusCode = StatusCodes.Status400BadRequest;
await context.Response.WriteAsync("Tenant is required.");
return;
}
context.Items["Tenant"] = tenant;
await next(context);
}
}
Tenant resolution must happen early enough that downstream services can use it.
Common storage models:
Shared database with tenant column:
Separate database per tenant:
There is no universal best option. The right model depends on tenant count, isolation needs, compliance, and operational maturity.
For shared-schema models, every tenant-owned row needs a tenant key.
public interface ITenantEntity
{
string TenantId { get; set; }
}
Global query filters can help:
modelBuilder.Entity<Order>()
.HasQueryFilter(o => o.TenantId == _tenantContext.TenantId);
This reduces accidental cross-tenant reads, but it is not a substitute for careful testing and authorization.
Tenants may have different settings:
Model it explicitly:
public sealed record TenantSettings(
string TenantId,
bool EnableAdvancedReports,
int MaxUsers);
Cache tenant settings carefully and invalidate them when changed.
Multi-tenancy raises the cost of mistakes. A cross-tenant data leak is a serious incident.
Controls:
Watch for these issues:
Multi-tenancy must be a first-class architectural concern. Add tenant context, isolation, testing, and observability early, because retrofitting them later is expensive.
Next Article: Real-Time Systems in .NET: SignalR Architecture and Scaling
]]>Before choosing a platform, answer:
Cloud choice is architecture. It affects configuration, networking, deployment, and operations.
Azure App Service is a managed platform for web apps and APIs.
Good fit:
Benefits:
Tradeoffs:
Azure Container Apps runs containers on a managed platform with scaling features.
Good fit:
Useful capabilities:
Container Apps is attractive when you want container packaging but not full cluster ownership.
Amazon ECS runs containers. Fargate lets you run ECS tasks without managing EC2 instances.
Good fit:
Core concepts:
Fargate reduces infrastructure management by removing the need to manage the underlying servers.
Across cloud platforms, keep the same .NET design:
appsettings.json for non-sensitive defaultsExample environment variable:
ConnectionStrings__Default=...
.NET configuration providers make this consistent across Azure, AWS, containers, and local development.
Cloud platforms need to know whether the app is healthy.
builder.Services.AddHealthChecks();
app.MapHealthChecks("/health");
For production, distinguish:
Scaling depends on the platform:
Use Azure App Service when:
Use Azure Container Apps when:
Use ECS/Fargate when:
Watch for these issues:
Cloud platforms differ, but the application fundamentals remain stable: external configuration, health checks, logs, metrics, secure secrets, and repeatable deployments.
Next Article: Multi-Tenancy Patterns in ASP.NET Core
]]>CI/CD reduces manual deployment risk. Every change should pass the same repeatable checks before it reaches users.
A baseline pipeline should answer:
Create .github/workflows/dotnet.yml:
name: dotnet-ci
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-dotnet@v4
with:
dotnet-version: '8.0.x'
- run: dotnet restore
- run: dotnet build --configuration Release --no-restore
- run: dotnet test --configuration Release --no-build
This is the minimum useful loop for most .NET repos.
After tests pass, publish the app:
- run: dotnet publish src/Store.Api/Store.Api.csproj --configuration Release --output ./publish
- uses: actions/upload-artifact@v4
with:
name: store-api
path: ./publish
Artifacts give later jobs a known package to deploy. This is better than rebuilding separately for every environment.
Never hard-code credentials in workflow files.
Use GitHub Actions secrets:
env:
ConnectionStrings__Default: $
Rules:
GitHub environments help control deployments.
Example:
deploy-staging:
runs-on: ubuntu-latest
environment: staging
needs: build
Production environments can require approvals, protection rules, and separate secrets.
A strong pipeline builds once and promotes the same artifact.
Why:
For containers, the equivalent is:
Useful checks include:
Do not add gates just to make the pipeline look sophisticated. Add checks that catch real risk for your project.
Watch for these issues:
CI/CD is not just automation. It is a reliability control that makes releases repeatable and traceable.
Next Article: Cloud Patterns for .NET: Azure App Service, Azure Container Apps, AWS ECS, and Fargate
]]>The basic publish command:
dotnet publish src/Store.Api/Store.Api.csproj -c Release -o publish
This creates deployable output with compiled assemblies, dependencies, and configuration files.
Use Release builds for deployment:
dotnet publish -c Release
Debug builds are for local development.
A typical multi-stage Dockerfile:
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish src/Store.Api/Store.Api.csproj -c Release -o /app/publish
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "Store.Api.dll"]
Build and run:
docker build -t store-api .
docker run -p 8080:8080 store-api
In containers, configuration usually comes from environment variables or mounted secrets, not edited files inside the image.
ASP.NET Core runs well on Linux. Common hosting options:
For systemd, your service file usually starts the published app and restarts it on failure.
In many Linux deployments, Nginx sits in front of Kestrel.
Nginx handles:
Basic reverse proxy shape:
server {
listen 80;
server_name api.example.com;
location / {
proxy_pass http://127.0.0.1:5000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
In ASP.NET Core, enable forwarded headers when running behind a proxy:
app.UseForwardedHeaders();
Health checks let platforms know whether the app is alive and ready.
builder.Services.AddHealthChecks();
var app = builder.Build();
app.MapHealthChecks("/health");
For production, consider separate endpoints:
Readiness may include database, cache, or message broker checks, but be careful not to make health checks too expensive.
Use this baseline:
Watch for these issues:
Deployment quality affects reliability directly. Treat startup, shutdown, logs, configuration, and health checks as part of the app contract.
Next Article: CI/CD with GitHub Actions for .NET: Build, Test, Publish, Secrets, and Environments
]]>gRPC is a remote procedure call framework that commonly uses:
It is a good fit for:
It is not always the best fit for public browser APIs unless you use gRPC-Web and account for ecosystem constraints.
Contracts live in .proto files.
syntax = "proto3";
option csharp_namespace = "Store.Grpc";
service ProductCatalog {
rpc GetProduct (GetProductRequest) returns (ProductReply);
}
message GetProductRequest {
int32 id = 1;
}
message ProductReply {
int32 id = 1;
string name = 2;
double price = 3;
}
The field numbers are part of the wire contract. Do not reuse them casually.
.NET generates a base class from the .proto file.
public sealed class ProductCatalogService : ProductCatalog.ProductCatalogBase
{
public override Task<ProductReply> GetProduct(
GetProductRequest request,
ServerCallContext context)
{
return Task.FromResult(new ProductReply
{
Id = request.Id,
Name = "Mechanical Keyboard",
Price = 129.00
});
}
}
Register gRPC:
builder.Services.AddGrpc();
var app = builder.Build();
app.MapGrpcService<ProductCatalogService>();
Generated clients make calls strongly typed.
var channel = GrpcChannel.ForAddress("https://localhost:5001");
var client = new ProductCatalog.ProductCatalogClient(channel);
var product = await client.GetProductAsync(new GetProductRequest { Id = 42 });
In real applications, configure gRPC clients through DI rather than constructing channels everywhere.
gRPC supports:
Server streaming example:
rpc StreamProducts (StreamProductsRequest) returns (stream ProductReply);
Implementation concept:
public override async Task StreamProducts(
StreamProductsRequest request,
IServerStreamWriter<ProductReply> responseStream,
ServerCallContext context)
{
await foreach (var product in productService.GetProductsAsync(context.CancellationToken))
{
await responseStream.WriteAsync(new ProductReply
{
Id = product.Id,
Name = product.Name,
Price = (double)product.Price
});
}
}
Streaming is useful when data arrives over time or when a response is too large to buffer comfortably.
Think about:
.proto files carefullyWatch for these issues:
.proto filesgRPC is a strong tool for typed service communication. Use it when its contract and streaming model simplify the system, not just because it is faster on paper.
Next Article: Deploying ASP.NET Core Apps: Docker, Linux Hosting, Nginx, and Health Checks
]]>The OWASP API Security Top 10 highlights common API failure modes. Examples include:
For .NET APIs, the practical response is:
A common bug is checking that a user is authenticated but not checking that they can access the specific record.
Bad:
[Authorize]
[HttpGet("orders/{id:int}")]
public async Task<IActionResult> GetOrder(int id)
{
return Ok(await repository.GetByIdAsync(id));
}
Better:
var order = await repository.GetByIdAsync(id);
if (order is null)
return NotFound();
if (order.CustomerId != currentUser.CustomerId)
return Forbid();
return Ok(order);
Authentication is not enough. Resource access must be checked.
Rate limiting protects APIs from abusive or accidental high-volume traffic.
Example:
builder.Services.AddRateLimiter(options =>
{
options.AddFixedWindowLimiter("api", limiter =>
{
limiter.PermitLimit = 100;
limiter.Window = TimeSpan.FromMinutes(1);
});
});
var app = builder.Build();
app.UseRateLimiter();
app.MapGet("/api/products", () => Results.Ok())
.RequireRateLimiting("api");
Rate limiting is especially important for:
CORS controls which browser origins can call your API. It is not an authentication system.
Example:
builder.Services.AddCors(options =>
{
options.AddPolicy("frontend", policy =>
{
policy
.WithOrigins("https://app.example.com")
.AllowAnyHeader()
.AllowAnyMethod();
});
});
app.UseCors("frontend");
Avoid:
.AllowAnyOrigin()
.AllowAnyHeader()
.AllowAnyMethod()
That may be acceptable for a local prototype, but it is usually too broad for production.
APIs and web apps benefit from security headers.
Common headers:
Strict-Transport-SecurityX-Content-Type-OptionsContent-Security-PolicyReferrer-PolicyExample middleware:
app.Use(async (context, next) =>
{
context.Response.Headers["X-Content-Type-Options"] = "nosniff";
context.Response.Headers["Referrer-Policy"] = "no-referrer";
await next();
});
For browser-facing apps, Content Security Policy deserves careful design and testing.
Use request DTOs and response DTOs. Avoid binding directly to EF Core entities.
Why:
Example:
public sealed record UpdateUserRequest(string DisplayName);
public sealed record UserResponse(int Id, string DisplayName);
Watch for these issues:
API security is a set of repeated habits. Authentication gets users in the door, but authorization, validation, limits, and observability keep the system defensible.
Next Article: gRPC in .NET: Contracts, Streaming, and Interop
]]>Before changing code, answer:
Useful tools:
dotnet-countersdotnet-traceDo not optimize a method because it looks inefficient. Optimize because evidence shows it matters.
Kestrel is the cross-platform web server used by ASP.NET Core.
Example configuration:
builder.WebHost.ConfigureKestrel(options =>
{
options.Limits.MaxRequestBodySize = 10 * 1024 * 1024;
options.Limits.KeepAliveTimeout = TimeSpan.FromMinutes(2);
options.Limits.RequestHeadersTimeout = TimeSpan.FromSeconds(30);
});
Tune Kestrel when:
Many apps should keep default Kestrel settings until measurements justify changes.
.NET has a highly optimized garbage collector, but allocation-heavy code still creates pressure.
Signs of allocation problems:
Use dotnet-counters:
dotnet-counters monitor --process-id 12345 System.Runtime
Watch counters such as:
Allocation reduction is most useful in hot paths.
Common improvements:
Example:
var builder = new StringBuilder();
foreach (var item in items)
{
builder.Append(item.Code);
builder.Append(',');
}
var result = builder.ToString();
Do not make code unreadable to avoid tiny allocations that do not matter. Keep optimization proportional to the measured cost.
BenchmarkDotNet is the standard .NET library for microbenchmarks.
Install:
dotnet add package BenchmarkDotNet
Benchmark:
[MemoryDiagnoser]
public class SlugBenchmarks
{
private readonly string _title = "Performance Tuning in .NET";
[Benchmark]
public string ReplaceSpaces()
{
return _title.ToLowerInvariant().Replace(" ", "-");
}
}
Run:
BenchmarkRunner.Run<SlugBenchmarks>();
Use BenchmarkDotNet for isolated algorithms and utility code. It does not replace end-to-end load tests.
A practical API tuning checklist:
AsNoTracking for read-only EF Core queriesWatch for these issues:
Performance tuning is disciplined measurement followed by focused changes. The best optimization is often changing what work the app does, not making unnecessary work slightly faster.
Next Article: Security Deep Dive for .NET APIs: OWASP, Rate Limiting, Headers, and CORS
]]>