Skip to content

Out-of-tree CMake restore ignores repository NuGet configuration #41915

Closed

Description

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:

  1. Configure an out-of-tree build with cmake -S . -B ../wsl-build.
  2. Inspect the restore's configuration and feed selection.
  3. 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.

Activity

  1. github-actions commented on Oct 14, 2026

    @github-actions
    Contributor

    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:

    Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
    Set-ExecutionPolicy Bypass -Scope Process -Force
    .\collect-wsl-logs.ps1
    

    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.

    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'.

  2. tunabirgun commented on Oct 14, 2026

    @tunabirgun
    ContributorAuthor

    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

  3. github-actions commented on Oct 14, 2026

    @github-actions
    Contributor

    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
    .wslconfig found
    Detected appx version: 2.6.3.0
    Found no WSL traces in the logs
    
  4. tunabirgun commented on Oct 14, 2026

    @tunabirgun
    ContributorAuthor

    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.

    WSL-active-guest-trace-public.tar.gz

  5. github-actions commented on Oct 14, 2026

    @github-actions
    Contributor
    Diagnostic information
    .wslconfig found
    Detected appx version: 2.6.3.0
    
  6. OneBlue commented on Oct 14, 2026

    @OneBlue
    Collaborator

    Fixed by #41916

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions