Perf: Workaround a nuget restore issue for MicroBenchmarks.csproj

[radical]

error NU1102: Unable to find package System.Text.Json with version (>= 8.0.0-rc.1.23375.7)
error NU1102:   - Found 1290 version(s) in dotnet8 [ Nearest version: 8.0.0-rc.1.23375.4 ]
error NU1102: Unable to find package System.Security.Cryptography.Xml with version (>= 8.0.0-rc.1.23375.7)
error NU1102:   - Found 1290 version(s) in dotnet8 [ Nearest version: 8.0.0-rc.1.23375.4 ]

Note the difference between the referenced version, and the one
available in the feed.

These packages are getting added as transitive references.

The hypothesis is that the direct package references have version string
as 8.0.*-* which select the latest available version.
- but those packages transitively reference others for whom the
latest version might not have been published to nuget yet.

To work around this, we add explicit references to such packages, so
they can get the versions selected from the ones in the feed.

Issue: #3164

[lewing]

I'm in favor of seeing if this resolves the restore problem and gets things building again, it has some unfortunate issues around what will actually get benchmarked but those already exist with other wildcards currently being used

[radical]

Testing this here - https://dev.azure.com/dnceng/internal/_build/results?buildId=2230266 .

[radical]

Though something to keep in mind is that the issue doesn't show up on every run, so if we don't want to merge, then we might have to run this a few times.

[ericstj]

What's the theory behind why this would even work? If it fixes anything at all it means we'd be testing in a torn configuration. I don't think we want to do that. Instead we'd just want to retry and hope that more packages were pushed.

[radical]

What's the theory behind why this would even work? If it fixes anything at all it means we'd be testing in a torn configuration. I don't think we want to do that. Instead we'd just want to retry and hope that more packages were pushed.

The retry might not help, because IIUC the package publishing can take some time. Maybe we should move the references to maestro based versions.

[cincuranet]

I'm working on the Maestro version.

[radical]

What's the theory behind why this would even work?

The hypothesis is that the direct package references have version string
as 8.0.- which select the latest available version.

• but those packages transitively reference others for whom the
  latest version might not have been published to nuget yet.
  To work around this, we add explicit references to such packages, so
  they can get the versions selected from the ones in the feed.

If it fixes anything at all it means we'd be testing in a torn configuration. I don't think we want to do that.

👍

The comment #3164 (comment) suggests that we should be using the maestro versions, which @cincuranet is working on. Considering that, I'm closing this PR.

[lewing]

What's the theory behind why this would even work? If it fixes anything at all it means we'd be testing in a torn configuration. I don't think we want to do that. Instead we'd just want to retry and hope that more packages were pushed.

As I mentioned in my comment it, my view is we're already potentially testing a torn configuration for any of the wildcard packs that are listed explicitly (there are a lot). I agree we need a better long term solution but I'm also extremely frustrated that I'm getting zero perf data as we approach rc1.

[LoopedBard3]

I agree we need a better long term solution but I'm also extremely frustrated that I'm getting zero perf data as we approach rc1.

Could you give some specifics for either what data is missing or where the data is missing? I want to make sure that there is not another issue occuring that is being overshadowed by this issue. Thanks!

[lewing]

#3181
#3180

are a couple