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

  1. git clone https://github.com/microsoft/devhome
  2. cd devhome/pluginsdk
  3. .\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)

Most upvoted comments

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:

  1. Add nuget.org package source to nuget.config at the top
  2. Comment out DevHomeDependencies package source
  3. Do a nuget restore
  4. Uncomment DevHomeDependencies to get the 2 internal packages
  5. Do another nuget restore.

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.

@snickler Ah, strange! On a clean box, that resolved it for me. But looks like the PR was just abandoned so the plot thickens.

I’m going to try again and remove all packages, clear out the binaries and try again. I may have been nuked by the ol MSBuild and VBCSCompiler processes caching things.

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.