That fixed E2E-, but only partially helped Integration-test. Looks like something's up with dependencies for folly, @dannyvv @asklar any ideas?

@AgneLukoseviciute It's unclear why some projects are ok and why some aren't. From what I can see, nuget.org is mentioned in the list of sources used towards the end, so this seems like something is broken with either the nuget task (i.e. it's not using the nuget from VS but instead it's using a custom nuget.exe that is incompatible), or the nuget.exe in VS is broken in recent builds.
Can you try running nuget sources before running the build or restores? That seemed to nudge another repo into picking the right nuget.exe. Also might want to look at running NugetToolInstall. If none of this works, please start a thread with VS Discussions or 1ES to figure out why we're still broken despite having a nuget.config.

Why are we dealing with nuget.exe at all in this yml? We build the app with run-windows, which restores the nuget packages we need. And if that doesn't work, then we need to fix run-windows.

Why are we dealing with nuget.exe at all in this yml? We build the app with run-windows, which restores the nuget packages we need. And if that doesn't work, then we need to fix run-windows.

@jonthysell
Agree we should fix the underlying issue, but I'd say higher priority is getting us unblocked and have code flowing again.
Note they only issue seems to be on the ADO/GH hosted agents where they changed some defaults that used to work. On local dev boxes there is still the default fallback. Note that Asklar also has a draft PR out to add nuget.config files to templates.

Has anyone tried the workaround mentioned in #7436

Register-PackageSource -Name MyNuGet -Location https://www.nuget.org/api/v2 -ProviderName NuGet -Trusted

Has anyone tried the workaround mentioned in #7436

Register-PackageSource -Name MyNuGet -Location https://www.nuget.org/api/v2 -ProviderName NuGet -Trusted

Haven't tried that here yet. I just added a nuget.config in the root of the repo as suggested fix in another thread, if this doesn't work I'll give that a shot.

I've rekicked this off since GH and ADO were out of sync. Hopefully now we'll get the pass.

The Folly project is still not seeing boost.

@jonthysell : The error is in the nuget packages path:
error: D:\a\1\s\packages\integration-test-app\windows\packages\boost.1.72.0.0\build\boost.targets
where nuget places the file at: Adding package 'boost.1.72.0' to folder 'D:\a\1\s\packages\integration-test-app\packages'
Due to the new nuget config having:

  <config>
    <add key="repositoryPath" value="packages" />
  </config>

which should probably be windows/packages which makes me confused how in e2e it does resolve to the right path... This nuget config merging is pretty opaque and non-intuitive....

@jonthysell Jon Thysell (JAUNTY) FTE : The error is in the nuget packages path:
error: D:\a\1\s\packages\integration-test-app\windows\packages\boost.1.72.0.0\build\boost.targets
where nuget places the file at: Adding package 'boost.1.72.0' to folder 'D:\a\1\s\packages\integration-test-app\packages'
Due to the new nuget config having:

  <config>
    <add key="repositoryPath" value="packages" />
  </config>

which should probably be windows/packages which makes me confused how in e2e it does resolve to the right path... This nuget config merging is pretty opaque and non-intuitive....

Lol, I just saw the same thing. The nuget.config should fix things, it just needs to be put into the windows folder. The e2e isn't resolving it to the right path, it's failing too. GH and ADO were out of sync. both failed in ADO but in GH it shows one as passed and the other as still running.

/azp run