devhome: Plugin SDK cannot be built due to private NuGet dependencies
Dev Home version
N/A
Windows build number
N/A
Other software
No response
Steps to reproduce the bug
git clone https://github.com/microsoft/devhome
cd devhome/pluginsdk
.\Build.cmd
Expected result
Build to execute/complete.
Actual result
.\Build.cmd
Directory: C:\Sources\devhome\pluginsdk
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 5/23/2023 10:22 AM _build
MSBuild auto-detection: using msbuild version '17.5.0.10706' from 'C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64'.
Restoring NuGet package Microsoft.Windows.CppWinRT.2.0.220531.1.
GET https://pkgs.dev.azure.com/ms/fef2e43c-84a1-4265-b74c-b824d387dd06/_packaging/3989942b-0a74-47bc-a7e3-ba19148bd858/nuget/v3/flat2/microsoft.windows.cppwinrt/2.0.220531.1/microsoft.windows.cppwinrt.2.0.220531.1.nupkg
[CredentialProvider]Using the ADAL UI flow for uri https://pkgs.dev.azure.com/ms/DevHome/_packaging/DevHomeDependencies/nuget/v3/index.json. User sign-in required in a pop-up authentication window.
[CredentialProvider]DeviceFlow: https://pkgs.dev.azure.com/ms/DevHome/_packaging/DevHomeDependencies/nuget/v3/index.json
[CredentialProvider]ATTENTION: User interaction required.
...
Included System Information
No response
Included Extensions Information
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 1
- Comments: 15 (7 by maintainers)
I’m encountering the same issue when building locally. Even after adding nuget.org package source to the top and clearing out the packages folder, I’m still getting random Microsoft.NETCore.App.Host-* and Microsoft.*.App.Ref package restore errors (due to auth permissions) when the DevHomeDependencies package source is there.
My workaround:
May be worth removing the upstream to nuget.org from the DevHomeDependencies Azure Artifact and adding the nuget.org source to the nuget.config separately.
Okay, I confirmed it should work with the nuget.org at the top. I had some weird caching of failures going on, along with doing the msbuild / dotnet way of doing a nuget restore, rather than using the nuget executable wrapper that the build command uses.
Nuget Executable: Reads package sources from Nuget.config in order / properly. MSBuild / .NET: Does not.
@snickler Ah, strange! On a clean box, that resolved it for me. But looks like the PR was just abandoned so the plot thickens.
Thanks @riverar, this should be fixed now.
I was able to build in a VM without putting in any credentials. @riverar - is your windows account a local one or an MSA? Mine was a “plain” (no internal MS binding) MSA.
edit: Disregard, missed that this was just the SDK project.