extensions: Cannot build solution locally
Description
As part of #4483 I tried to build the solution locally, but package restore fails.
At first it failed with this error:
C:\Coding\dotnet\extensions\eng\common\internal\Tools.csproj : error NU1100: Unable to resolve 'Microsoft.ManifestTool.CrossPlatform (>= 2.1.3)' for '.NETFramework,Version=v4.7.2'. PackageSourceMapping is enabled, the following source(s) were not considered: dotnet-core-internal-tooling. [C:\Coding\dotnet\extensions\extensions.sln]
C:\Coding\dotnet\extensions\eng\common\internal\Tools.csproj : error NU1100: Unable to resolve 'Microsoft.VisualStudioEng.MicroBuild.Core (>= 1.0.0)' for '.NETFramework,Version=v4.7.2'. PackageSourceMapping is enabled, the following source(s) were not considered: dotnet-core-internal-tooling. [C:\Coding\dotnet\extensions\extensions.sln]
C:\Coding\dotnet\extensions\eng\common\internal\Tools.csproj : error NU1100: Unable to resolve 'Microsoft.VisualStudioEng.MicroBuild.Plugins.SwixBuild (>= 1.1.286)' for '.NETFramework,Version=v4.7.2'. PackageSourceMapping is enabled, the following source(s) were not considered: dotnet-core-internal-tooling. [C:\Coding\dotnet\extensions\extensions.sln]
Then I edited NuGet.config to add the following:
<packageSource key="dotnet-core-internal-tooling">
<package pattern="*" />
</packageSource>
Now the build fails with the following error because I don’t have access to the AzDo package feed for DevDiv:
C:\Coding\dotnet\extensions\eng\common\internal\Tools.csproj : error NU1301: Unable to load the service index for source https://pkgs.dev.azure.com/devdiv/_packaging/dotnet-core-internal-tooling/nuget/v3/index.json. [C:\Coding\dotnet\extensions\extensions.sln]
Reproduction Steps
Run restore.cmd while not being a Microsoft employee.
Expected behavior
The solution successfully builds.
Actual behavior
The solution fails to restore NuGet packages.
Regression?
Unsure.
Known Workarounds
Get hired by Microsoft to work in DevDiv 😄
Configuration
8.0.100-rc.2.23462.28
Other information
No response
About this issue
- Original URL
- State: closed
- Created 9 months ago
- Comments: 28 (28 by maintainers)
Commits related to this issue
- Add solution file Resolves #4488. — committed to martincostello/extensions by martincostello 9 months ago
- Disable VS Code solution file creation Prevent C# Dev Kit from creating a solution file if the repository is opened in Visual Studio Code. Resolves #4488. — committed to martincostello/extensions by martincostello 9 months ago
- Disable VS Code solution file creation (#4517) Prevent C# Dev Kit from creating a solution file if the repository is opened in Visual Studio Code. Resolves #4488. — committed to dotnet/extensions by martincostello 9 months ago
Thank you, we appreciate your feedback.
Ahh – good find @martincostello . thanks for figuring that out.
Yes, we should have a sln file then. Would you perhaps push your working one up as a PR?
this may be a side note but… succeeding on Linux or Linux-like systems but failing on Windows is expected when the problem is the code attempting to real sign without appropriate rights to the Microbuild tooling. what you want to find in the binary log are the properties causing the Windows build to attempt real signing outside an official build. or, look at the sign-related properties in the pipeline YAML to see what settings should be conditional
I think here
https://developercommunity.visualstudio.com/dotnet?ftype=problem
It’s for .NET Framework but ignore that.