Plugin SDK cannot be built due to private NuGet dependencies
See original GitHub issueDev 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
Issue Analytics
- State:
- Created 4 months ago
- Reactions:1
- Comments:15 (7 by maintainers)
Top Results From Across the Web
Unable to resolve dependencies of NuGet packages
Solution · Clear the NuGet cache files. You do this in the following way: In the toolbar of Visual Studio, navigate to Tools...
Read more >NuGet problems after moving my Visual Studio extension ...
The nuget package has dependencies are >= 16.8.39 . ... version of dependencies, but the new-sdk style project cannot automatically identify ...
Read more >Referencing a Local Private NuGet Package in your Solution
I recently needed to add a local reference to my project and I couldn't quite figure out the best way to do it...
Read more >Create a .NET Core application with plugins
An AssemblyDependencyResolver is used to resolve the dependencies of the plugin. The tutorial correctly isolates the plugin's dependencies ...
Read more >MSBuild reference for .NET SDK projects
The CopyLocalLockFileAssemblies property is useful for plugin projects that have dependencies on other libraries. If you set this property to ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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.