dotnet nuget does not respect libraries set in setup-dotnet with UseWPF enabled to true
See original GitHub issueDescription
Follow on from https://github.com/actions/virtual-environments/issues/1451#issuecomment-678974940 We are working on our first set of WPF user control libraries. Local restore works perfectly fine using the APP_DATA/nuget.config file. When we push to GitHub actions on a windows runner, any NuGet package we reference which has UseWPF set to true is not restored correctly (appears to be using the wrong config).
Any NuGet package we reference which is not using WPF restores fine.
Details
Output of setup-dotnet
Run actions/setup-dotnet@v1 with: dotnet-version: 3.1.101 source-url: https://nuget.pkg.github.com/lekolabs/index.json env: NUGET_AUTH_TOKEN: *** C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -Sta -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command "& 'D:\a\_actions\actions\setup-dotnet\v1\externals\get-os-platform.ps1'" Primary:win-x64 Checking tool cache 3.1.101 Getting a download url 3.1.101 Checking tool cache 3.1.101 Extracting Package D:\a\_temp\87ce5eca-f463-420b-bdb5-8501b188d135 C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -Sta -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command "$ErrorActionPreference = 'Stop' ; try { Add-Type -AssemblyName System.IO.Compression.FileSystem } catch { } ; [System.IO.Compression.ZipFile]::ExtractToDirectory('D:\a\_temp\87ce5eca-f463-420b-bdb5-8501b188d135', 'D:\a\_temp\83edb1ac-fb43-4410-a535-79bf3b7d7b60')" Caching tool Successfully installed 3.1.101 dotnet-auth: Finding any source references in D:\a\_temp\nuget.config, writing a new temporary configuration file with credentials to D:\a\nuget.config
Output of restore
`The .NET Core tools collect usage data in order to help us improve your experience. The data is anonymous. It is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to ‘1’ or ‘true’ using your favorite shell.
Read more about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry
Explore documentation: https://aka.ms/dotnet-docs Report issues and find source on GitHub: https://github.com/dotnet/core Find out what’s new: https://aka.ms/dotnet-whats-new Learn about the installed HTTPS developer cert: https://aka.ms/aspnet-core-https Use ‘dotnet --help’ to see available commands or visit: https://aka.ms/dotnet-cli-docs Write your first app: https://aka.ms/first-net-core-app
Restore completed in 156.34 ms for D:\a\Leko-Lux-Repo-KrusiApplication\Leko-Lux-Repo-KrusiApplication\LekoKrusiAppSolution\LekoKrusiApp.Infra\LekoKrusiApp.Infra.csproj. D:\a\Leko-Lux-Repo-KrusiApplication\Leko-Lux-Repo-KrusiApplication\LekoKrusiAppSolution\LekoKrusiApplication\LekoKrusiApplication.csproj : error NU1101: Unable to find package LekoUserControls. No packages exist with this id in source(s): Microsoft Visual Studio Offline Packages, nuget.org, Source [D:\a\Leko-Lux-Repo-KrusiApplication\Leko-Lux-Repo-KrusiApplication\LekoKrusiAppSolution\LekoKrusiAppSolution.sln] Restore completed in 1.09 min for D:\a\Leko-Lux-Repo-KrusiApplication\Leko-Lux-Repo-KrusiApplication\LekoKrusiAppSolution\LekoKrusiApp.Implementation\LekoKrusiApp.Implementation.csproj. Restore failed in 1.09 min for D:\a\Leko-Lux-Repo-KrusiApplication\Leko-Lux-Repo-KrusiApplication\LekoKrusiAppSolution\LekoKrusiApplication\LekoKrusiApplication.csproj. Restore completed in 7.54 ms for D:\a\Leko-Lux-Repo-KrusiApplication\Leko-Lux-Repo-KrusiApplication\LekoKrusiAppSolution\SecretManagement\SecretManagement.csproj. Restore completed in 6.66 sec for D:\a\Leko-Lux-Repo-KrusiApplication\Leko-Lux-Repo-KrusiApplication\LekoKrusiAppSolution\LekoMetricsLambda\LekoMetricsLambda.csproj. ##[error]Process completed with exit code 1.`
Notice that restore of LekoUserControls does not list our lekolabs source, which should have been included.
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (4 by maintainers)
Top GitHub Comments
@ZEisinger I added an explicit NuGet.Config with the clear sources attribute at the repo level, and observed that while our additional source is referenced in the output, the file could not be found.
This lead to us finding that the service account was not approved for access to read the repository when it was created.
Once we fixed that, and removed the explicit NuGet, we retried with
@main
and had success.Thanks for the update @LekoLabs-DerekDiebold