Repository navigation
Conversation
…s natural location The MoveSymbolFiles target in src/coreclr/Directory.Build.targets copied every managed project's PDB into a single flattened $(RuntimeBinDir)PDB\ folder after each build. Besides being unnecessary busywork for the ~25 projects whose PDBs are copied there but never consumed from that location, this consolidation caused a real bug: projects with multiple build variants that share an assembly name (e.g. crossgen2's normal and published builds) would race to overwrite each other's PDB in the shared folder, so the PDB left behind in PDB\ did not necessarily match the DLL actually shipped. The only real consumer of this folder, eng/liveBuilds.targets' ResolveRuntimeFilesFromLocalBuild target (used when other subsets assemble the shared framework from an already-built clr subset), only ever looked up System.Private.CoreLib.pdb and System.Private.CoreLib.ni.pdb from it. - System.Private.CoreLib.ni.pdb is already written directly to the PDB\ folder by crossgen-corelib.proj, independent of MoveSymbolFiles. - System.Private.CoreLib.pdb (the managed/IL PDB) is produced by CoreLib's own compile and naturally lands at $(RuntimeBinDir)IL\System.Private.CoreLib.pdb, identical to the copy MoveSymbolFiles produced. This change removes the MoveSymbolFiles target and its associated item group entirely, and updates ResolveRuntimeFilesFromLocalBuild to read the managed CoreLib PDB directly from its natural IL\ location (mirroring the existing DLL fallback already present in that target), removing the need for the copy mechanism altogether. Validated by rebuilding the clr subset (no errors, no behavior change for consumers of the shared framework) and by directly invoking AddRuntimeFilesToPackage on Microsoft.NETCore.App.Runtime.CoreCLR.sfxproj, confirming System.Private.CoreLib.pdb resolves correctly from its natural location. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 099eec3c-119a-4097-8071-6cd952af9e7c
|
Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
|
Tagging subscribers to this area: @dotnet/runtime-infrastructure |
This was referenced Oct 8, 2026
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
CoreLib’s PDB is no longer placed where Core_Root’s configured symbol paths can discover it.
1 open finding
What changed in this PR
Removes broad managed-PDB consolidation and resolves CoreLib’s managed PDB directly from its build output.
Changes:
- Deletes
MoveSymbolFiles. - Uses
IL/System.Private.CoreLib.pdbfor runtime packaging. - Leaves a Core_Root symbol-path regression requiring correction.
| File | Description |
|---|---|
src/coreclr/Directory.Build.targets |
Removes managed-PDB consolidation. |
eng/liveBuilds.targets |
Resolves CoreLib’s PDB from the IL directory. |
🧠 Review effort: Balanced
The IL/System.Private.CoreLib.pdb and IL/System.Private.CoreLib.dll paths used a literal forward slash, producing a different string than the backslash-separated path the SharedFramework SDK's symbol-file discovery reconstructs via %(RootDir)%(Directory)%(FileName)%(Extension) for every ReferenceCopyLocalPaths item on Windows. Because MSBuild's RemoveDuplicates compares raw ItemSpec strings without normalizing separators, the two equivalent-but-differently-spelled paths were not deduplicated, causing NuGet to reject the second add with NU5118. Introduce CoreCLRArtifactsILDir, built with [MSBuild]::NormalizeDirectory like the existing CoreCLRArtifactsPdbDir, and use it for both the CoreLib DLL fallback and PDB RuntimeFiles entries so the resolved paths are consistently separator-normalized. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 099eec3c-119a-4097-8071-6cd952af9e7c
Removing MoveSymbolFiles stopped consolidating System.Private.CoreLib.pdb into the PDB/ folder; it now only exists under IL/ (as copied into Core_Root by CoreRootArtifacts.targets). Helix's _NT_SYMBOL_PATH only searched PDB/, so VM _ASSERTE() stack walks could no longer resolve CoreLib's managed symbols. Append IL/ to the Helix symbol search path, matching the existing multi-directory _NT_SYMBOL_PATH precedent in src/libraries/sendtohelixhelp.proj. Native shared-framework symbols (coreclr, clrjit, etc.) are unaffected: they are installed into PDB/ directly by the native CMake build (install_symbol_file), independent of MoveSymbolFiles. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 099eec3c-119a-4097-8071-6cd952af9e7c
A literal ';' inside an MSBuild Include attribute is the item-list separator, so the previous commit's _NT_SYMBOL_PATH value was split into two HelixPreCommand items: the 'set' command ending at '\PDB', and a second command consisting of just the '\IL' path, which Helix would try to execute directly instead of using it as the second symbol search directory. Escape the separator as %3B, matching the existing precedent in src/libraries/sendtohelix-browser.targets. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 099eec3c-119a-4097-8071-6cd952af9e7c
This branch has not been deployed
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
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.
MoveSymbolFilesinsrc/coreclr/Directory.Build.targetscopied every managed project's PDB into a flattened$(RuntimeBinDir)PDB\folder. This was mostly unused busywork and also caused a real bug: build variants sharing an assembly name (e.g. crossgen2's normal vs. published builds) could overwrite each other's PDB in the shared folder, so the PDB left behind didn't necessarily match the shipped DLL.The only real consumer,
eng/liveBuilds.targets'sResolveRuntimeFilesFromLocalBuild, only ever looked upSystem.Private.CoreLib.pdb/.ni.pdbfrom that folder..ni.pdbis already written there directly bycrossgen-corelib.proj; the managed.pdbis produced by CoreLib's own compile atIL\System.Private.CoreLib.pdb(verified byte-identical to the old copy).This removes
MoveSymbolFilesentirely and updates the consumer to read the managed CoreLib PDB from its naturalIL\location, mirroring the existing DLL fallback already there.Validation: clean
clrsubset rebuild (no errors); direct invocation ofAddRuntimeFilesToPackageonMicrosoft.NETCore.App.Runtime.CoreCLR.sfxprojconfirmsSystem.Private.CoreLib.pdbresolves correctly fromIL\.Note
This PR description and implementation were generated with GitHub Copilot.