Const vs readonly in C#: use const for compile-time literals that never change and readonly for runtime-initialized values that should not change after construction. This article shows clear rules, .NET 8 examples with Dependency Injection, and production considerations so you pick the right tool every time.
The Problem
Mixing const and readonly without intent leads to brittle releases, hidden performance costs, and binary-compatibility breaks. You need a simple, reliable decision framework and copy-paste-ready code that works in modern .NET 8 Minimal APIs with DI.
Prerequisites
- .NET 8 SDK: Needed to compile and run the Minimal API and C# 12 features.
- An editor (Visual Studio Code or Visual Studio 2022+): For building and debugging the examples.
- Azure CLI (optional): If you apply the security section with Managed Identity and RBAC for external configuration.
The Solution (Step-by-Step)
1) What const means
- const is a compile-time constant. The value is inlined at call sites during compilation.
- Only allowed for types with compile-time constants (primitive numeric types, char, bool, string, and enum).
- Changing a public const value in a library can break consumers until they recompile, because callers hold the old inlined value.
// File: AppConstants.cs
namespace MyApp;
// Static class is acceptable here because it only holds constants and does not manage state or dependencies.
public static class AppConstants
{
// Compile-time literals. Safe to inline and extremely fast to read.
public const string AppName = "OrdersService"; // Inlined at compile-time
public const int DefaultPageSize = 50; // Only use if truly invariant
}
2) What readonly means
- readonly fields are assigned exactly once at runtime: either at the declaration or in a constructor.
- Use readonly when the value is not known at compile-time (e.g., injected through DI, environment-based, or computed) but must not change after creation.
- static readonly is runtime-initialized once per type and is not inlined by callers, preserving binary compatibility across versions.
// File: Slug.cs
namespace MyApp;
// Simple immutable value object using readonly field.
public sealed class Slug
{
public readonly string Value; // Assigned once; immutable thereafter.
public Slug(string value)
{
// Validate then assign. Once assigned, cannot change.
Value = string.IsNullOrWhiteSpace(value)
? throw new ArgumentException("Slug cannot be empty")
: value.Trim().ToLowerInvariant();
}
}
3) Prefer static readonly for non-literal shared values
- Use static readonly for objects like Regex, TimeSpan, Uri, or configuration-derived values that are constant for the process lifetime.
// File: Parsing.cs
using System.Text.RegularExpressions;
namespace MyApp;
public static class Parsing
{
// Compiled Regex cached for reuse. Not a compile-time literal, so static readonly, not const.
public static readonly Regex SlugPattern = new(
pattern: "^[a-z0-9-]+$",
options: RegexOptions.Compiled | RegexOptions.CultureInvariant
);
}
4) Minimal API (.NET 8) with DI using readonly
// File: Program.cs
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Options;
namespace MyApp;
// Options record for settings that may vary by environment.
public sealed record PaginationOptions(int DefaultPageSize, int MaxPageSize);
// Service depending on options. Primary constructor for clarity.
public sealed class ProductService(IOptions<PaginationOptions> options)
{
private readonly int _defaultPageSize = options.Value.DefaultPageSize; // readonly: set once from DI
public IResult List(int? pageSize)
{
// Enforce immutable default from DI; callers can't mutate _defaultPageSize
var size = pageSize is > 0 ? pageSize.Value : _defaultPageSize;
return Results.Ok(new { PageSize = size, Source = "DI/readonly" });
}
}
var builder = WebApplication.CreateBuilder(args);
// Bind options from configuration once. Keep them immutable after construction.
builder.Services.Configure<PaginationOptions>(builder.Configuration.GetSection("Pagination"));
// Register ProductService for DI.
builder.Services.AddSingleton<ProductService>();
var app = builder.Build();
// Use const for literal routes and tags: truly invariant strings.
app.MapGet("/products", (ProductService svc, int? pageSize) => svc.List(pageSize))
.WithTags(AppConstants.AppName);
app.Run();
5) When to use which (decision rules)
- Use const when: the value is a true literal that will never change across versions, and you accept inlining (e.g., mathematical constants, semantic tags, fixed route segments).
- Use readonly when: the value is computed, injected, environment-specific, or may change across versions without forcing consumer recompilation.
- Use static readonly for: reference types (Regex, TimeSpan, Uri) or structs not representable as compile-time constants, shared across the app.
- Avoid public const in libraries for values that might change; prefer public static readonly to avoid binary-compat issues.
6) Performance and threading
- const reads are effectively free due to inlining.
- static readonly reads are a single memory read; their initialization is thread-safe under the CLR type initializer semantics.
- RegexOptions.Compiled with static readonly avoids repeated parsing and allocation under load.
7) Advanced: readonly struct for immutable value types
- Use readonly struct to guarantee all instance members do not mutate state and to enable defensive copies avoidance by the compiler.
- Prefer struct only for small, immutable value types to avoid copying overhead.
// File: Money.cs
namespace MyApp;
public readonly struct Money
{
public decimal Amount { get; }
public string Currency { get; }
public Money(decimal amount, string currency)
{
Amount = amount;
Currency = currency;
}
// Methods cannot mutate fields because the struct is readonly.
public Money Convert(decimal rate) => new(Amount * rate, Currency);
}
8) Binary compatibility and versioning
- Public const values are inlined into consuming assemblies. If you change the const and do not recompile consumers, they keep the old value. This is a breaking behavior.
- Public static readonly values are not inlined. Changing them in your library updates behavior without requiring consumer recompilation.
- Guideline: For public libraries, avoid public const except for values guaranteed to never change (e.g., mathematical constants or protocol IDs defined as forever-stable).
9) Testing and static analysis
- Roslyn analyzers: Enable CA1802 (use const) to suggest const when fields can be made const; enable IDE0044 to suggest readonly for fields assigned only in constructor.
- CI/CD: Treat analyzer warnings as errors for categories Design, Performance, and Style to enforce immutability usage consistently.
- Unit tests: Assert immutability by verifying no public setters exist and by attempting to mutate through reflection only in dedicated tests if necessary.
10) Cross-language note: TypeScript immutability parallel
If your stack includes TypeScript, mirror the C# intent with readonly and schema validation.
// File: settings.ts
// Strict typing; no 'any'. Enforce immutability on config and validate with Zod.
import { z } from "zod";
// Zod schema for runtime validation
export const ConfigSchema = z.object({
apiBaseUrl: z.string().url(),
defaultPageSize: z.number().int().positive(),
}).strict();
export type Config = Readonly<{
apiBaseUrl: string; // readonly by type
defaultPageSize: number; // readonly by type
}>;
export function loadConfig(env: NodeJS.ProcessEnv): Config {
// Validate at runtime, then freeze object to mimic readonly semantics
const parsed = ConfigSchema.parse({
apiBaseUrl: env.API_BASE_URL,
defaultPageSize: Number(env.DEFAULT_PAGE_SIZE ?? 50),
});
return Object.freeze(parsed) as Config;
}
Best Practices & Security
- Best Practice: Use const only for literals that are guaranteed stable across versions. For anything configuration-related, prefer readonly or static readonly loaded via DI.
- Best Practice: Static classes holding only const or static readonly are acceptable because they do not manage state or dependencies.
- Security: If loading values from Azure services (e.g., Azure App Configuration or Key Vault), use Managed Identity instead of connection strings. Grant the minimal RBAC roles required: for Azure App Configuration, assign App Configuration Data Reader to the managed identity; for Key Vault, assign Key Vault Secrets User; for reading resource metadata, the Reader role is sufficient. Do not embed secrets in const or readonly fields.
- Operational Safety: Avoid public const for values that may change; use public static readonly to prevent consumer inlining issues and to reduce breaking changes.
- Observability: Expose configuration values carefully in logs; never log secrets. If you must log, redact or hash values and keep them in readonly fields populated via DI.
Summary
- Use const for true compile-time literals that never change; prefer static readonly for public values to avoid consumer recompilation.
- Use readonly (and static readonly) for runtime-initialized, immutable values, especially when sourced via DI or environment configuration.
- Harden production: enforce analyzers in CI, adopt Managed Identity with least-privilege RBAC, and avoid embedding secrets or changeable values in const.
