You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Out-of-tree CMake configuration can ignore the repository's NuGet feed. restore_nuget_packages supplies -SolutionDirectory with the build directory but does not explicitly select the source tree's nuget.config.
With NuGet 5.10.0 and a separate build directory, the restore used the user configuration and nuget.org. Required dependencies, including Microsoft.Identity.MSAL.WSL.Proxy 0.1.1, were unavailable there. Passing -ConfigFile with the repository configuration selected the declared WSL feed and restored the package.
Reproduction:
Configure an out-of-tree build with cmake -S . -B ../wsl-build.
Inspect the restore's configuration and feed selection.
Compare a cache-disabled restore without an explicit configuration against the same restore with -ConfigFile <source>/nuget.config, using separate empty package directories.
The focused negative control exited 1 because the package was absent from nuget.org; the positive control exited 0 using the repository feed. The full project build has not been verified. A minimal fix is to pass the repository configuration explicitly in cmake/findNuget.cmake.
If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'. Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.
How to collect WSL logs
Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:
The script will output the path of the log file once done.
If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues
Once completed please upload the output files to this GitHub issue.
If you choose to email these logs instead of attaching them to the bug, please send them to [email protected] with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.
Attached are a fresh package-restore diagnostic report and a default-profile WSL capture from an isolated Windows test VM running WSL 2.6.3.0.
The package report is the relevant evidence for this build-time issue: separate, initially empty restore directories produced exit 1 with the default nuget.org configuration and exit 0 with the repository configuration. The full project build remains unverified.
The WSL capture used the official collector with only its interactive wait replaced by a 20-second delay. No dumps or service restart were requested. Three optional Windows licensing fields were removed from the public archive; the ETL and all other member contents are unchanged. The test VM could not resolve the package feeds, so its trace is diagnostic context rather than a successful reproduction of the NuGet comparison. No WSL runtime logs were collected from the development host.
The first capture lacked WSL provider activity. This replacement was recorded with WPR confirmed active before wsl --status, a root-session launch, and wsl --list --running in the isolated test VM. tracerpt parsed 4,763 events with none lost, including WSL device-host and 9P provider events.
The collector used the default profile and a 60-second timed wait, without dumps or service restart. Only three optional Windows licensing fields were removed; the ETL is unchanged. This trace provides WSL runtime context. The package-restore report in the preceding comment remains the evidence for the build-configuration defect addressed by #41916.
Activity
github-actions commentedon Oct 14, 2026
Logs are required for review from WSL team
If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.
How to collect WSL logs
Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:
The script will output the path of the log file once done.
If this is a networking issue, please use
.\collect-wsl-logs.ps1 -LogProfile networkinginstead, following the instructions in Collect WSL logs for networking issuesOnce completed please upload the output files to this GitHub issue.
See Collect WSL logs (recommended method).
If you choose to email these logs instead of attaching them to the bug, please send them to [email protected] with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.
tunabirgun commentedon Oct 14, 2026
Attached are a fresh package-restore diagnostic report and a default-profile WSL capture from an isolated Windows test VM running WSL 2.6.3.0.
The package report is the relevant evidence for this build-time issue: separate, initially empty restore directories produced exit 1 with the default nuget.org configuration and exit 0 with the repository configuration. The full project build remains unverified.
The WSL capture used the official collector with only its interactive wait replaced by a 20-second delay. No dumps or service restart were requested. Three optional Windows licensing fields were removed from the public archive; the ETL and all other member contents are unchanged. The test VM could not resolve the package feeds, so its trace is diagnostic context rather than a successful reproduction of the NuGet comparison. No WSL runtime logs were collected from the development host.
The proposed configuration fix is in #41916.
WSL-guest-diagnostics-public.tar.gz
WSL-build-restore-diagnostics.txt
github-actions commentedon Oct 14, 2026
The log file doesn't contain any WSL traces. Please make sure that you reproduced the issue while the log collection was running.
Diagnostic information
tunabirgun commentedon Oct 14, 2026
The first capture lacked WSL provider activity. This replacement was recorded with WPR confirmed active before
wsl --status, a root-session launch, andwsl --list --runningin the isolated test VM.tracerptparsed 4,763 events with none lost, including WSL device-host and 9P provider events.The collector used the default profile and a 60-second timed wait, without dumps or service restart. Only three optional Windows licensing fields were removed; the ETL is unchanged. This trace provides WSL runtime context. The package-restore report in the preceding comment remains the evidence for the build-configuration defect addressed by #41916.
WSL-active-guest-trace-public.tar.gz
github-actions commentedon Oct 14, 2026
Diagnostic information
OneBlue commentedon Oct 14, 2026
Fixed by #41916