start-vs-VisualFSharpSln.ps1: build against the hive's own Roslyn - #20467
Open
xperiandri wants to merge 2 commits into
Open
xperiandri wants to merge 2 commits into
xperiandri wants to merge 2 commits into
Conversation
Contributor
✅ No release notes required |
github-actions
Bot
added
⚠️ Affects-Build-Infra
Contributor
|
🔍 Tooling Safety Check — Affects-Build-Infra, Affects-Restore
|
xperiandri
changed the title
start-vs-VisualFSharpSln.ps1: build against the hive's own Roslyn
T-Gro
reviewed
Sep 9, 2026
F5 loads the extension into a hive (RootSuffix), and that hive's own deployed Roslyn wins over the installed VS's when one is present: a locally built Roslyn deployed there stamps itself 42.42.42.42 and redirects every reference to itself via a hive-level binding redirect. The script detected the installed VS's Roslyn version and overrode the repo's packages to match it unconditionally, which built against the wrong version whenever the target hive carried its own Roslyn - RoslynDev in particular, the hive this repo's own DEVGUIDE points contributors at. It now reads devenv.isolation.ini to find the hive's own Extensions folder first, and only falls back to the installed VS's Roslyn when the hive has none of its own. A new -RootSuffix parameter names the hive (default RoslynDev, matching the VisualFSharpDebug launch profile). When the detected version's minor matches what the repo's Version.Details.props already flows, no override is written at all - the common case for a hive built from this same source - and a locally built hive Roslyn with no package version at all now fails fast asking for one instead of silently building against packages that do not match what will actually load. The override file also moves to its own path (RoslynOverride.start-vs.props) so a build-vs-VisualFSharpSln.ps1 run in the same session cannot silently overwrite it, since a long-lived VS process restores against whatever CustomAfterMicrosoftCommonProps last pointed at. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
-RootSuffix only chose which hive to read the Roslyn version from: the VSIX projects hard-coded VSRootSuffix to RoslynDev, and that is both the hive F5 deploys into and the /rootsuffix launchSettings passes, so -RootSuffix Foo built against Foo's Roslyn and then ran in RoslynDev. VSRootSuffix now defaults to RoslynDev only when nothing set it, and the script hands its suffix to the Visual Studio it launches, whose builds read it from the environment. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
xperiandri
force-pushed
the
start-vs-hive-roslyn
branch
from
September 11, 2026 15:34
6ddb240 to
a9b6737
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
F5loads the F# extension into a hive named byRootSuffix, and that hive's own deployed Roslyn wins over the installed VS's whenever one is present: a locally built Roslyn deployed into a hive stamps itself42.42.42.42and adds a hive-level binding redirect so every reference resolves to it. The script only ever looked at the installed VS's shipped Roslyn, so it built against the wrong version whenever the target hive carried its own —RoslynDevin particular, whichDEVGUIDE.mdalready points contributors at for this exact script.It now reads
devenv.isolation.inito find the hive's ownExtensionsfolder first, and only falls back to the installed VS's shipped Roslyn when the hive has none of its own. A new-RootSuffixparameter names the hive (defaultRoslynDev, matching theVisualFSharpDebuglaunch profile). When the detected version's minor already matches whateng/Version.Details.propsflows, no override file is written at all — the common case for a hive built from this repo's own source — and a locally built hive Roslyn with no package version now fails fast asking for-RoslynVersioninstead of silently building against mismatched packages.-RootSuffixalso decides where the extension runs, not just which Roslyn it is built against. The hive F5 deploys into and the/rootsuffixthatlaunchSettings.jsonpasses both come fromVSSDKTargetPlatformRegRootSuffix, whichvsintegration/Vsix/Directory.Build.propsderived from a hard-codedVSRootSuffix. That property now defaults toRoslynDevonly when nothing set it, and the script passes its suffix to the Visual Studio it launches through the environment. Builds that do not go through the script are unchanged: with nothing set the VSIX projects still resolveRoslynDev.The override file also moves to its own path (
RoslynOverride.start-vs.props) so abuild-vs-VisualFSharpSln.ps1run in the same session can't silently overwrite it — a long-lived VS process restores against whateverCustomAfterMicrosoftCommonPropslast pointed at.Tooling only; no compiler or IDE code path changes, so no release notes entry.
Checklist
🤖 Generated with Claude Code