Update xunit version on release branch

[maryamariyan]

Cherry pick of #59275

Resolved conflicts:
eng/Versions.props

[ghost]

Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Cherry pick of #59275

Resolved conflicts:
eng/Versions.props

Author:	maryamariyan
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[ericstj]

Per offline conversation, @maryamariyan identified the failures here were caused by xunit/xunit@87322e9#diff-002769cbe13c8eb7dfb43a11a837108f0c269aedb5999a7495dad878826ee013L16

That change included NETStandard.Library which increased the number of package we saw in these test project graphs which overlap with projects. NuGet assumes that our projects should be used, but those no longer support the older TFMs and thus the restore failure.

@maryamariyan will follow up with @bradwilson and @clairernovotny to see if that change was intentional and see if we want that in user projects.

We can workaround it by adding a newer NETStandard.Library package reference to these test projects, since the newer package will avoid package references on frameworks where the assembly is inbox, rather than relying on that package to apply no asset (as we did in 1.x).

[ViktorHofer]

We can workaround it by adding a newer NETStandard.Library package reference to these test projects, since the newer package will avoid package references on frameworks where the assembly is inbox, rather than relying on that package to apply no asset (as we did in 1.x).

We're already doing that at least for .NETCoreApp:

runtime/eng/testing/xunit/xunit.targets

Lines 4 to 6 in 03bc2c2

	<PackageReference Include="NETStandard.Library"
	Version="$(NetStandardLibraryVersion)"
	Condition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp'" />

[ViktorHofer]

see comments

[bradwilson]

What's the proposed fix on the xUnit.net side?

[ericstj]

What's the proposed fix on the xUnit.net side?

I think it would be to add back the empty dependency group, so that it's like this:

[bradwilson]

I was led astray by the tooling. 😂 Version 2.4.2-pre.11 is on MyGet with the fix.

[ericstj]

I was led astray by the tooling.

I see. The empty dependency group is a manual optimization folks did a lot with netstandard1.x that the tooling doesn't know about. An empty dependency group is correct and beneficial because NETStandard.Library is supported inbox on that framework. We've discussed helping folks make these optimizations in package validation, but we haven't implemented it yet and that wouldn't silence the nuget warning.

Technically you can "teach" nuget about the empty dependency group by cross-compiling for net452 and not referencing any packages: we did this for a lot of our netstandard packages to reduce package graph size and avoid app-local facades (for netstandard2.0). I think applying nowarn is the smallest fix to do in servicing, thank you @bradwilson for making this fix.

[ericstj]

Merging this infrastructure reliability fix as tell-mode.