Evaluate .NET 11 SDK, runtime and BCL improvements

GitVersion opportunities in .NET 11

Research snapshot: 2026-09-15. No performance measurements or implementation changes have been made.

Recommendation

At GA, complete the existing additive migration, adopt the SDK for tooling, and measure runtime-only gains before introducing new APIs. The best small implementation candidate is the managed backend's process-output capture. Span-based decompression merits a bounded experiment only if profiling identifies object inflation as material. Defer GC tuning, collection rewrites, runtime-async opt-in, NativeAOT, and packaging-format changes.

No performance improvement has been established for GitVersion. Official runtime microbenchmarks establish mechanisms, not application speedups.

Scope and evidence baseline

• Local checkout: bd1f3031893f96104f879ad6343a787ebebe074a. Paths below refer to this revision, not the PR branch.
• PR #5207, read live at 754ad91fe10ab83b96b19b50255910e553986223, is open and draft. Its scope already includes stable net10/net11 multi-targeting, MSBuild tool selection, SDK RC1, and dual-runtime Docker coverage. Its description retains net10 standalone archives, build tooling, and experimental CLI targets; full cross-platform packaging and Windows task-host verification remain open. Description-reported validation is not independently audited CI evidence here.
• PR #5209 is merged (2026-09-15). C# syntax, language/compiler/parser policy are excluded from this proposal.

Official sources

These are mutable sources checked on the research date; refresh at GA. Microsoft Learn overview/search snapshots lagged the RC1 detail pages, so release status uses the release announcement/download page and features use the RC1 source documents.

Repository boundaries

Ranked opportunities

Benefit is qualitative and conditional. Evidence distinguishes existence of a platform feature from proof it helps this application.

1. SDK, build and publish tooling

S4 documents a NativeAOT dotnet entry point, including out-of-process tool resolution/launch, and a default warm MSBuild server. The former is relevant to dotnet gitversion; a direct dotnet-gitversion shim or standalone executable has a different launch path. The latter may help the repeated project invocations in UnitTest.cs, but isolated CI jobs may not retain a warm worker. Neither turns GitVersion into a NativeAOT application.

Linux/macOS SDK assembly deduplication reduces SDK installation footprint (S4). This can help CI/development image acquisition. It does not establish smaller GitVersion packages or runtime-only images. Preserve symlinks if tooling copies SDK directories. Measure compressed downloads and unpacked size separately.

At GA, retarget the Cake executables only as planned, checking addins, package/coverage/docs tasks and generated artifacts. Do not update every package major simply because the SDK changes. S4's SDK container reproducibility features apply to PublishContainer; existing Cake/Docker workflows do not acquire them automatically. A container-pipeline rewrite has insufficient benefit here.

MTP options are possibilities, not proposed command changes. In particular, skipping dependency builds conflicts with the intentional snapshot-path rebuild in UnitTest.cs:58. A current-runtime shortcut would also undermine explicit net10/net11 coverage. S4 records RC1 relative-project-path failures, all-skipped exit-code issues and reduced exit-code diagnostics; check the referenced SDK fixes at GA and do not silently reinterpret failures as success. No local test commands were executed or proposed.

2. Automatic runtime benefits, startup and memory

Running on runtime 11 makes JIT/BCL improvements available without rewriting GitVersion. Recompilation alone with SDK 11 while still executing net10 does not do that. Net11 API use needs a net11 reference surface; changing generated R2R/native code requires publishing again.

S2 documents broader generic/default-interface devirtualization, constant folding and bounds-check elimination. These could affect managed traversal and parsing, but no exact optimized call site has been proven. Inspect src/GitVersion.Git.Managed/History/GitRevisionWalker.cs:29 (commit cache), its dictionaries/sets at lines 77, 128 and 299, and GitPackMemoryCache.cs:31 for representative allocation-heavy workloads. Native libgit2 internals do not become faster from managed JIT improvements; wrappers and surrounding calculation can still benefit.

S2 documents R2R specialization of default comparers. Its operation-level benchmark is not an expected GitVersion multiplier. Distinguish framework R2R improvements available with the installed runtime from choosing R2R for GitVersion application assemblies. No new publish default is recommended.

No reviewed official evidence establishes a GitVersion-specific GC improvement. Track allocated bytes, collection counts/pause time and peak process memory; distinguish retained caches from transient garbage and native allocations. Keep GC settings unchanged. A short CLI may finish before steady-state tiered optimizations matter, while repeated invocations in a long-lived host have different behavior.

Runtime Async remains a preview opt-in for application code in S2. Runtime libraries already use it, so their changes can be inherited while leaving GitVersion code alone. The new CLI's async entry point (Program.cs:24) is not evidence that runtime-async migration will matter. Defer explicit opt-in and broad async rewrites.

3. Process APIs: the most concrete small follow-up

src/GitVersion.Git.Managed/CommandLine/GitCliExecutor.cs:63 creates a Process, two StringBuilders and two ManualResetEventSlim instances, wires both output events, waits for exit and drains both streams. S3 provides RunAndCaptureText/async helpers and documents overlapped redirected I/O on Windows. The underlying Windows improvement may be inherited on runtime 11 even without using a new helper.

Preserve the existing IGitCliExecutor/GitCliResult contract and process configuration: ArgumentList, working directory, no credential prompts, locale, removal of inherited Git repository variables, credential-redacted logs, nonzero exit handling and missing-Git exception. The current event handler normalizes lines via AppendLine; whole-text capture could preserve original newlines/final-line termination instead. Decide and test this explicitly. Exercise simultaneous large stdout/stderr to prove complete capture, plus empty output, Unicode, spaces in arguments, missing executable and nonzero exits. Existing src/GitVersion.Core.Tests/Core/GitCliMutatorTests.cs covers the surrounding integration; a focused executor test would be new work requiring review.

Net10 support means a conditional net11 implementation plus unchanged fallback, or deferral until the fallback can be removed. Prefer one small private boundary; do not spread conditional compilation through callers. Adding timeouts, process-tree termination or cancellation would change semantics and is outside a capture-only patch. New process APIs do not remove the managed backend's dependency on the Git executable for mutation.

4. I/O and compression: measure before implementation

GitPack.cs:41 opens index/pack files lazily. GitZLibStream.cs:33 validates the two-byte zlib header and wraps a DeflateStream; reads and forward seeking carry additional state. S3's span-based Deflate/ZLib decoders and Reset support could reduce stream allocations for repeated objects, but require input/output buffer ownership, partial decode handling and correct decoder reuse.

Do not substitute a full-buffer decode for lazy reads: large blobs, delta chains and concurrent cache views may increase peak memory. GitPackMemoryCacheStream.cs:12 grows a MemoryStream on demand; GitPackMemoryCacheViewStream.cs:48 coordinates views and positions. Fixed memory adapters are not replacements for these behaviors. Validate against GitZLibStreamTests.cs, LooseObjectTests.cs, PackedObjectTests.cs and malformed/truncated/delta-boundary cases in src/GitVersion.Git.Managed.Tests/.

S3's pipe support in RandomAccess/SafeFileHandle is useful for process plumbing, not evidence to rewrite regular-file pack reading. Existing FileStream use already receives applicable runtime fixes. Avoid low-level pipe ownership changes alongside the process helper.

Zstandard is a new compression option, not a replacement for Git's zlib object representation. Defer it for both repository storage and release archives. Existing Cake.Compression abstractions may use different libraries; .NET ZIP behavior changes are relevant only where the actual path uses those BCL APIs. Archive extraction/listing compatibility is part of packaging validation, not a reason to redesign archive formats.

5. Collections and other APIs to defer

S3 adds BitArray span constructors/PopCount and a key-selector EqualityComparer factory. The inspected traversal uses GitObjectId-keyed sets/dictionaries, not an existing BitArray algorithm. Converting to bitsets would require assigning dense IDs and change algorithm/memory tradeoffs. No .NET 11 justification was found for it. The comparer factory may simplify a future exact call site; it is not a performance optimization by itself.

Do not rebrand existing span APIs, Frozen collections, alternate lookup or generic collection tuning as new .NET 11 work. Mutable caches are not candidates for blanket freezing. JSON/new stream helpers warrant adoption only at a demonstrated allocation/behavior need, and never by pulling net11 runtime dependencies into the netstandard generator. No such production call site was established here.

Compatibility and maturity gates

RC1 go-live support does not override the GA merge gate. Revalidate final SDK/runtime pins, support policy and API signatures. .NET 10 remains the LTS compatibility baseline; do not invent a final .NET 11 support-end date from preview information.

S5 raises the x86/x64 baseline and distinguishes that hard requirement from newer R2R targets, which can fall back to JIT. S2 and S5 disagree on the Windows Arm64 minimum in their current text; do not publish a definitive Arm64 claim until the final compatibility note/runtime matrix agree. Include representative older supported CPUs in startup validation where feasible.

Keep native libgit2 RID assets, OS libraries, musl/glibc and architecture checks in artifact CI. Single-file native extraction and Windows MSBuild task hosts deserve explicit smoke tests. New-cli still references LibGit2Sharp; generated commands alone do not prove trimming or NativeAOT compatibility. Defer either deployment conversion until a separate dependency/reflection audit and measurable startup requirement justify it.

Measurement design

Use CI artifacts and controlled runners, not local builds in this research. Hold source SHA, fixture repository, configuration, output mode, backend, CPU/OS, Git/native-library versions and package versions constant. Record actual loaded runtime and SDK. Compare (a) the same compatible net10 IL on runtimes 10/11 with explicit runtime selection, then (b) equivalent net10/net11 builds, then any isolated API or publish change. The existing LatestMajor setting makes accidental cross-contamination possible.

Measure direct executable versus dotnet gitversion, first process versus repeated process, cache miss versus cache hit, loose versus packed repositories, small versus large histories and representative shallow/worktree layouts. Repeated fresh processes are not in-process JIT warm-up. Record elapsed time distributions, CPU, allocation/GC data, peak RSS/working set, bytes read and artifact/download size. Benchmark new-cli separately with redirected input: its Program.cs:25 can otherwise wait for a key.

Require unchanged semantic version variables/JSON and exit behavior. Compare both backends where available; do not attribute Git child-process time or native allocations to managed GC. Use enough repetitions to show variance and confidence intervals; predeclare a practical improvement threshold before inspecting results. Keep noisy performance experiments separate from correctness gates. Publish exact-SHA results and limitations before claiming benefit.

Proposed .NET 11 follow-ups

Status: proposed follow-up; implementation not started. The research below records source evidence, repository references and uncertainty.

Proposed sequence

A. Finish existing GA migration; do not duplicate it

Owner surface: draft #5207.

• At GA, refresh SDK/runtime/container pins and confirm final API and platform requirements.
• Preserve stable net10/net11 support, MSBuild selection/fallback and net10 standalone archive policy already covered there.
• Verify final-head CI for managed and LibGit2Sharp backends, retained frameworks, real packed tool installation, MSBuild consumers/task hosts, OS/RID artifacts and native loading.
• Resolve the official Windows Arm64 documentation discrepancy before documenting final requirements.
• Exclude all syntax/compiler/parser modernization covered by #5209/#5207.

Acceptance: reviewable final GA artifacts and current-head CI evidence. An earlier green commit or PR description alone is insufficient.

B. Narrow tooling adoption at GA

Potential files: global.json, build/Directory.Build.props, build/Directory.Packages.props, relevant setup workflows. Change only what remains after A.

• Retarget Cake tooling as planned and verify installed addin/module compatibility using CI's build, package, test-report and docs tasks.
• Keep experimental CLI target changes separate from stable distribution policy; do not retarget new-cli/GitVersion.Cli.Generator/GitVersion.Cli.Generator.csproj away from netstandard2.0.
• Retain explicit test framework selection and the stable snapshot-path rebuild. No automatic adoption of skip-dependencies/current-runtime options.
• Check RC1 MTP issues against the GA SDK; preserve meaningful failures and reported counts.

Acceptance: full relevant CI and stable generated/package outputs. Do not mix new API changes into this patch.

C. Establish CI performance evidence

First proposed new work after review: a bounded benchmark job or existing performance-harness extension, selected after checking the current harness. No permanent benchmark dependency or workflow has been added by this research.

• Start with stable CLI launch + calculation on one controlled runner and pinned small/large packed repositories.
• Separate SDK launch overhead, runtime-only effects and net11 compilation; confirm loaded runtimes rather than infer them from TFM.
• Compare managed/libgit2, direct/tool launch, cold/warm repository cache, and elapsed/CPU/allocation/peak-memory metrics.
• Expand to Windows/macOS and new-cli only when the initial comparison is repeatable. Redirect new-cli input to avoid its interactive wait.
• Archive source SHA, inputs, runtime/SDK versions, raw measurements and output parity. Agree practical thresholds before assessing the result.

Acceptance: reproducible distributions and no version/output regressions. A neutral result is useful and does not trigger an API rewrite.

D. Optional process capture patch

Proceed only after A–C and review of the net10 fallback maintenance cost.

Potential production file: src/GitVersion.Git.Managed/CommandLine/GitCliExecutor.cs only, plus focused tests selected during implementation.

• Keep the public/internal caller contract and process configuration unchanged.
• Use the final net11 capture helper behind one conditional boundary; preserve net10 behavior.
• Resolve line-ending/final-newline semantics explicitly.
• Validate large simultaneous streams, exit codes, missing Git, Unicode, arguments, working directory, environment scrubbing and redacted logs on both target frameworks.
• Measure again; describe maintainability improvement separately from speed.

Acceptance: parity demonstrated in CI, no deadlock/data loss, no new behavior such as timeout or cancellation. If the helper needs comparable custom synchronization or conditional complexity, defer the patch.

E. Conditional decompression experiment

Proceed only if C attributes meaningful cost to managed object inflation.

Candidate boundary: src/GitVersion.Git.Managed/GitZLibStream.cs, with adjacent object/pack readers inspected before edits. Prototype a final net11 streamless decoder without replacing cache architecture.

Acceptance: existing format/header semantics, partial-read/seek behavior, truncated input, delta objects and lifetime handling remain correct; measurable end-to-end benefit and no peak-memory regression. Otherwise discard the experiment. Keep any prototype separate from default production behavior.

Deferred

• NativeAOT/trimming and application-wide R2R defaults: dependency audit and startup evidence required.
• Explicit Runtime Async: preview maturity and workload relevance unresolved.
• GC tuning, bitset/frozen-cache rewrites and broad async conversion: no established bottleneck.
• Zstandard archive/storage changes and SDK-container pipeline migration: poor fit or separate product decision.
• BCL stream adapters/comparer factories without a demonstrated local need.

Review decision

Recommended next work: A/B at GA and C as a separate measurement task. Keep D optional and E dependent on profiling. No production changes are needed merely to benefit from the SDK/runtime improvements.