Marko Apfel
Development

Why You Should Never Set LangVersion=Latest in a Serious Project

Why pinning LangVersion to Latest undermines build reproducibility, and how explicit language and SDK versions keep a team's builds predictable.

2 min read

It’s an easy setting to add and an easy one to regret: LangVersion=Latest in your .csproj. It looks harmless — who wouldn’t want the newest C# language features as soon as they’re available? In practice, though, it trades away exactly the kind of predictability that a serious software project depends on.

What LangVersion=Latest actually does

By default, a project compiles against the C# version tied to the installed .NET SDK. Setting LangVersion explicitly to Latest overrides that and forces the compiler to always use the newest stable language version the installed SDK supports:

<PropertyGroup>
  <LangVersion>Latest</LangVersion>
</PropertyGroup>

The catch is in that word “installed.” The behavior of your build now depends on whichever SDK happens to be on the machine running it — which is not something you want to leave to chance.

Why that’s a problem

Unintended breaking changes. Microsoft occasionally introduces breaking changes between minor SDK updates. With Latest in place, a routine SDK update — on a developer’s machine or in CI — can silently change what your code compiles to, or stop it from compiling at all. Pinning to an explicit version like LangVersion=11.0 keeps your code’s behavior stable across SDK upgrades.

Dependency and tooling friction. Editors, linters, static analysis tools, and third-party libraries don’t always keep pace with the newest language features. Latest increases the odds of IDE warnings, analyzer incompatibilities, or friction integrating with older projects — all avoidable by naming a stable version explicitly.

Inconsistency across the team. If teammates have different SDK versions installed, Latest means they’re not even compiling against the same language version. That’s a recipe for reviews that argue about syntax nobody agreed to use yet, and bugs that only reproduce on some machines.

What to do instead

Pin the language version explicitly:

<PropertyGroup>
  <LangVersion>11.0</LangVersion>
</PropertyGroup>

And pair it with a global.json at the repository root to pin the SDK version itself, so CI and every developer machine build against the same toolchain:

{
  "sdk": {
    "version": "8.0.100"
  }
}

Together, these two settings remove an entire category of “works on my machine” bugs.

The takeaway

LangVersion=Latest optimizes for one thing — always having the newest syntax available — at the cost of the thing that actually matters in a team setting: a build that behaves the same way regardless of who runs it or when. Choose language and SDK versions explicitly, upgrade them on purpose, and keep surprises out of the codebase.

Further reading