Documented precedence for RemovePreviousVersion: All versus .NET 10

Question

Documented precedence for RemovePreviousVersion: All versus .NET 10

Manica Moscon Advogados 5

The pinned Windows installation guide, under “Choose when previous versions are removed,” lists general All and version-specific .NET 10 settings for RemovePreviousVersion. It also states that invalid values default to always.

https://github.com/dotnet/docs/blob/951c3a5bdf253157f9b403e1f490bc42f5171fbc/docs/core/install/windows.md

What documented rule determines the effective value when both settings are present, and how is that value determined when the .NET 10 entry is absent or invalid?

Please provide a primary documentation reference and the relevant passage, preferably versioned where available. If the evidence comes from implementation rather than a published contract, please distinguish it. I am not assuming that an absent or invalid version-specific entry falls back to All.

This is a documentation clarification request. No registry access or changes, installations, or execution tests have been performed for this request.

Manica Moscon Advogados 5 Reputation points

2026-11-04T17:40:19.16+00:00

Thank you for the references. PR 14975 documents intended version-specific precedence, but its description covers search infrastructure only and says nothing yet acts on the value. That PR targets release/6.0 and is closed.

Could you provide a primary versioned reference, preferably immutable, showing where the Windows .NET 10 SDK installer actually applies RemovePreviousVersion, including selection between general and version-specific settings when the specific entry is absent or invalid, and whether fallback occurs?

Please distinguish a published installer contract from implementation evidence and identify the applicable SDK/release scope, including 10.0.403 or 10.0.114 where supported by the reference. A focused reference to the selection and application logic is sufficient. For the file linked on main, a pinned revision would make the evidence reproducible.

2 answers

Your answer

Manica Moscon Advogados 5 Reputation points

2026-11-04T17:40:19.16+00:00

Thank you for the references. PR 14975 documents intended version-specific precedence, but its description covers search infrastructure only and says nothing yet acts on the value. That PR targets release/6.0 and is closed.

Could you provide a primary versioned reference, preferably immutable, showing where the Windows .NET 10 SDK installer actually applies RemovePreviousVersion, including selection between general and version-specific settings when the specific entry is absent or invalid, and whether fallback occurs?

Please distinguish a published installer contract from implementation evidence and identify the applicable SDK/release scope, including 10.0.403 or 10.0.114 where supported by the reference. A focused reference to the selection and application logic is sufficient. For the file linked on main, a pinned revision would make the evidence reproducible.

Answer 1

Hello @Manica Moscon Advogados ,

Thank you for raising this documentation question. I understand why the earlier references do not fully satisfy your request for release-specific evidence.

Based on the available public information, the intended behavior is that the version-specific RemovePreviousVersion value takes precedence when present. If it is absent, the general value under HKLM\SOFTWARE\Microsoft\.NET is used. Once the applicable value has been selected, an invalid value defaults to always.

However, the Windows installation documentation only lists the supported registry locations and values. It does not expressly document that precedence and fallback rule, including whether an invalid version-specific entry remains selected or falls back to the general value.

As you noted, Arcade PR #14975 describes the intended version-specific precedence, but it concerns the earlier release/6.0 implementation and does not show the complete selection and application path for a released .NET 10 SDK installer.

I was unable to locate a primary, immutable public reference tying that complete logic specifically to SDK 10.0.403 or 10.0.114. Therefore, although the behavior above is consistent with the available implementation information, I cannot confirm it as an expressly published or release-specific .NET 10 installer contract.

For release-specific confirmation, I recommend raising this with the .NET installer maintainers in the dotnet/arcade repository. They would be in the best position to identify the source revision used by those SDK releases and clarify whether this behavior is intended as a documented contract or remains implementation-defined.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation. Thank you.

Nguyen Dam (WICLOUD CORPORATION) 1,335 Reputation points Microsoft External Staff Moderator

2026-11-10T01:58:51.6133333+00:00

Hello @Manica Moscon Advogados ,

I wanted to follow up in case you have received any further clarification from the .NET installer maintainers or found additional release-specific evidence since your last update. If anything further comes up regarding this question, please feel free to follow up here.
Nguyen Dam (WICLOUD CORPORATION) 1,335 Reputation points Microsoft External Staff Moderator

2026-11-12T02:10:08.36+00:00

Hello @Manica Moscon Advogados ,

Just checking in once more to see if you have any further questions regarding my previous response. Please feel free to follow up if there is anything else I can help clarify.

Answer 2

The effective rule is: if the .NET 10-specific RemovePreviousVersion value exists, it takes precedence over All; if it is absent, the global All value is used; whichever selected value is invalid resolves to always.

Published documentation

The Windows installation guide documents both registry locations and the value normalization rules:

| .NET version | Registry key | Name | Type | Value |
| All | HKLM\SOFTWARE\Microsoft\.NET | RemovePreviousVersion | REG_SZ | always, never, or nextSession |
| .NET 10 | HKLM\SOFTWARE\Microsoft\.NET\10.0 | RemovePreviousVersion | REG_SZ | always, never, or nextSession |

It then states:

always removes previous installations after the new version is installed. This is the default behavior in .NET.

and:

Values are case-insensitive and invalid values default to always.

The feature applies only to standalone installer executables and is available starting with .NET 8 servicing release 8.0.11.^1^

However, that published article does not currently state the precedence or fallback rule between the global and version-specific entries. Therefore, precedence is not established by that article alone.

Precedence established by implementation work

The change that introduced the registry searches states explicitly:

The search operation will check for a global and version specific registry key. The version specific key takes precedence when present.

That wording is in Arcade PR #14975.^2^

The installer policy source implements separate searches for:

the global value under SOFTWARE\Microsoft\.NET;
existence of the version-specific value under SOFTWARE\Microsoft\.NET\<major>.<minor>;
the version-specific value, conditionally searched when that entry exists.^3^

Consequently, the decision table for a .NET 10 standalone installer is:

`.NET\10.0` entry	Global `All` entry	Effective input	Effective behavior
Present and valid	Any value or absent	Version-specific value	`always`, `never`, or `nextSession`
Present but invalid	Valid or absent	Invalid version-specific value	`always`
Absent	Present and valid	Global value	Global setting
Absent	Present but invalid	Invalid global value	`always`
Absent	Absent	Default	`always`

The important distinction is that fallback is based on presence, not validity. An invalid .NET 10 value is still the selected version-specific value; it does not fall back to All. The documented invalid-value rule then converts it to always.

Contract status

Published contract: accepted values are case-insensitive; invalid values and the default resolve to always; the global and per-version locations are supported.
Implementation-defined/documented in the introducing PR: a present version-specific entry overrides the global entry.
Documentation gap: the Learn article does not expressly say that absence triggers global fallback while an invalid version-specific value does not.

A documentation clarification could state:

The version-specific RemovePreviousVersion value takes precedence when present. If it is absent, the value under HKLM\SOFTWARE\Microsoft\.NET is used. After selecting the applicable value, values are evaluated case-insensitively, and an invalid or unavailable value defaults to always.

References