Repeatability becomes a container-publishing control
Microsoft released .NET 11 Release Candidate 1 on September 8, 2026. The release spans the runtime, libraries, SDK, build tools and application frameworks, but two SDK changes address a particularly concrete engineering problem: keeping automated builds and tests predictable. Container publishing can now produce the same digest from the same inputs when a stable timestamp is supplied, while test runs gain limits that apply across all participating test applications. These controls reduce avoidable variation in continuous-integration systems without promising that the resulting software is correct or secure.
Before RC1, publishing an unchanged application more than once could still generate different container digests. Microsoft attributes that variation to timestamps, archive headers and directory enumeration order. A digest is a cryptographic identifier calculated from an image manifest and its referenced content. Deployment systems commonly use it to distinguish exact artifacts. If incidental metadata changes the digest, two builds made from equivalent source and dependencies can appear different, weakening cache efficiency and complicating comparisons during audits or incident investigations.
The new path uses SOURCE_DATE_EPOCH, an established reproducible-build convention expressed as a Unix timestamp. Microsoft’s example derives the value from the latest Git commit and passes it to the container-publishing target. With that stable value and otherwise identical inputs, independent publishes can produce the same digest. This is more useful than merely assigning the same human-readable tag, because tags can be moved between images. A stable digest gives release systems a precise identity to compare across build attempts.
A matching digest is evidence of sameness, not safety
Deterministic output can help a team answer a narrow but important question: did this build process produce the same artifact from the same declared inputs? It can also expose unexplained variation. If two supposedly equivalent builds still differ, engineers have a smaller search area for nondeterministic tools, environmental inputs or undeclared dependencies. Stable identities can improve promotion workflows in which one tested artifact moves between environments instead of being rebuilt separately for staging and production.
That value has strict boundaries. The mechanism depends on stable inputs as well as a consistently chosen epoch. A source tree, compiler, base image, dependency, environment setting or build argument that changes legitimately changes the result. Conversely, repeatably producing one digest does not show that the source was authorized, that dependencies are free of vulnerabilities or that the application behaves correctly. Reproducibility supports provenance and investigation, but it is not a security scan, signature, software bill of materials or certification.
Teams also need to preserve the evidence surrounding a build. A digest is most useful when it can be related to source revision, dependency resolution, builder identity, configuration and test results. RC1 does not automatically establish that complete chain. It supplies one missing property inside it: the SDK can stop timestamps and ordering details from creating needless differences. Organizations still decide how to authenticate builders, sign outputs, control registries and retain attestations.
Registry publishing avoids work that is already complete
RC1 also changes how the SDK publishes to a remote container registry. It first checks whether the computed manifest already exists in the destination repository. When there is a match, the publishing path skips processing the layers and configuration while still applying every requested tag. That can reduce repeated work when a pipeline republishes an artifact under an environment-specific or release-specific label without changing its contents.
The optimization is enabled by default, but it can be bypassed with the ContainerPushNoCache property. Microsoft says the SDK continues checking individual configuration and layer blobs and avoids uploading blobs already present in the registry. These checks are distinct from the reproducible-build feature. A stable digest makes identical artifacts easier to recognize, while registry inspection determines whether their components or manifest already exist at the destination.
The benefit depends on registry state and network behavior, and Microsoft did not publish an independent transfer-cost study with RC1. A manifest match can avoid processing and uploads, but it does not remove authentication, tag updates, policy evaluation or every registry request. It also does not prove that the existing remote artifact arrived through an approved pipeline. Access controls, immutable-tag policies and signed provenance remain separate operational decisions.
Test limits now cover the complete run
Large .NET test commands can launch multiple test applications, particularly for solutions and projects targeting several frameworks. RC1 adds controls at the complete-run level when dotnet test uses Microsoft.Testing.Platform. Options placed before the double hyphen belong to the overall run, while options after it continue to pass through to each test application. That distinction lets an orchestration command enforce one budget instead of relying on every subordinate process to interpret its own limit.
The new timeout accepts milliseconds, seconds or minutes. It counts time while at least one test application is running and returns exit code 3 when the limit is reached. A separate maximum-failed-tests option stops after a configured number of failed, errored, timed-out or cancelled results and returns exit code 13. These specific exit codes let continuous-integration systems distinguish an exhausted time budget from a failure-count threshold instead of treating every interrupted run as the same event.
Such limits are useful when a regression causes a suite to stall or produce a cascade of failures. Stopping after enough evidence has accumulated can release build capacity sooner and make the initiating failure easier to inspect. The controls do not decide which threshold is appropriate, and stopping early means some tests will remain unexecuted. They are resource and feedback controls, not evidence that the unexecuted portion would have passed.
Result isolation addresses a quieter source of lost evidence
RC1 introduces a per-module results-directory layout for solution and multi-targeted runs. Each test application receives a separate output directory, preventing reports with the same relative filename from overwriting one another. The default remains a flat layout, so teams must select the new organization when it fits their reporting tools. When the SDK artifacts layout is enabled, reports, coverage data and diagnostics receive a structured default location unless an explicit results path takes precedence.
This change matters because test evidence can be lost without a test itself failing. Two modules may both emit a file called results.xml or a coverage report under the same relative path. If one replaces the other, a later dashboard can present an incomplete record while the original run appears successful. Separating outputs by project and target pivot preserves the relationship between evidence and the test application that produced it, although downstream collectors must understand the directory structure.
Other SDK work in RC1 follows the same effort to remove incidental cost. File-based Native AOT programs can reuse compatible build outputs, and dotnet format now searches for configuration through ancestors of included files instead of unrelated subtrees. Microsoft reports one monorepo example improving from 1.09 seconds to 0.55 seconds when formatting one included file. That is a project-specific development measurement, not a general performance benchmark.
Go-live support does not turn RC1 into general availability
Microsoft describes RC1 as the first .NET 11 release candidate and provides it under a go-live support license. That designation means Microsoft permits supported production use under the applicable terms. It does not make RC1 the final generally available release, and it is not a security certification. The official release index identifies .NET 11 as a planned Standard Term Support release with a support period beginning November 10, 2026, which marks the scheduled general-release stage rather than the September candidate.
Production adoption therefore involves a maturity tradeoff. Teams can validate the reproducible-container and test-run controls against realistic pipelines before general availability, and some may use the supported candidate where the benefits justify the remaining release risk. They must still review documented breaking changes. One RC1 change allows the Configuration environment variable to supply the default for shared command-line options, which may select a different build configuration in scripts that already set that variable.
The strongest contribution in this portion of RC1 is greater control over evidence. Builds can carry stable identities, registry operations can recognize completed work, test commands can stop under explicit budgets and outputs can remain separated by module. Each improvement is bounded and inspectable. Together they make automation easier to reason about, while leaving source trust, application correctness, security assessment and final release readiness to other parts of the engineering system.