[rc2] Revert to stable MSBuild and Roslyn versions

[AndriySvyryd]

Description
VMR doesn't produce the stable version of Roslyn packages (see dotnet/roslyn#78298), so EF GA packages would depend on prerelease versions. To avoid this EF will be built against the stable N-1 versions for GA and then switch to the newest version for the first servicing release. The GA version will have limited functionality in some cases due to this: MSBuild integration will not work for net10.0 projects and NativeAOT will not be supported because precompiled query generation will fail.

Customer impact
Without this GA official build will fail due to a prerelease dependency and even if that check is overridden the EFC.Design package won't be able to resolve dependencies, see dotnet/sdk#50697

How found
Validation

Regression
Yes, from 10.0.0-rc1, introduced in #36707

Testing
Tested manually

Risk
Low, this reverts to previously used versions, so the limitations are known.

[dibarbet]

To avoid this EF will be built against the stable N-1 versions for GA and then switch to the newest version for the first servicing release. The GA version will have limited functionality in some cases due to this: MSBuild integration will not work for net10.0 projects and NativeAOT will not be supported because precompiled query generation will fail.

FYI - we should be able to publish Roslyn stable packages to nuget.org for dev18 preview 1 soon (~days to a week). So should hopefully unblock you for net10 projects even if they aren't the very tip of the Roslyn changes.

[dibarbet]

At the moment, the next Roslyn packages that will be publicly available on nuget.org will be 5.0.0-2.final (corresponding to dev18 preview 1). But neither 5.0.0 nor 5.0.0-2.final exist yet so not critical here.

I will let you know if that changes as we move towards VMR publishing.

[mmitche]

@AndriySvyryd The Version.Details.xml file doesn't match up, and auto-generated Version.Details.props file still has the old values.

[AndriySvyryd]

@AndriySvyryd The Version.Details.xml file doesn't match up, and auto-generated Version.Details.props file still has the old values.

What are the consequences of leaving it that way apart from noise in the source code update PRs?

[artl93]

Critical for shipping

[mmitche]

@AndriySvyryd The Version.Details.xml file doesn't match up, and auto-generated Version.Details.props file still has the old values.

What are the consequences of leaving it that way apart from noise in the source code update PRs?

I think it will generate a failure in dependency flow PRs. Properties shouldn't be duplicated between VErsions.props and Version.Details.props, and Version.Details.props is driven off Version.Details.xml