Pin assembly versions to prevent revving those in servicing releases

[RussKie]

Resolves dotnet/core#7172 (comment)
This is a complimentary work to dotnet/winforms#6667

Proposed changes

• Lock runtime and targeting pack assemblies at 6.0.2.0 so that any applications, libraries or NuGets built against 6.0.2 or later can work.
  This assembly versions pinning is similar to https://github.com/dotnet/runtime/blob/bbc766a7c65716305919bc691d696b1e46fa6f62/eng/Versions.props#L14 and https://github.com/dotnet/aspnetcore/blob/c0575788ecadd6e5cfeb4eab635c13b5fd433d37/Directory.Build.targets#L88.
• Add a validation step when we run packaging to verify that the assemblies we package into the transport package are correctly versioned, i.e., analyzers/generators are revved for every release for sxs, and those part of the ref pack are pinned to X.Y.2.0.

Customer Impact

Currently WPF applications built against 6.0.2 won't run on 6.0 GA or 6.0.1
With the fix applications, libraries or NuGets built against 6.0.2 or later can work. Any applications built on 6.0.2 or later that need to target 6.0.0 or 6.0.1 will need to use the workaround provided in dotnet/core#7176. It is not ideal, but is believed to have a lesser impact than going back to 6.0.0.0 versions, and have 6.0.2 broken.

Regression?

• Yes

Risk

• Medium. With this fix we'll stop supporting the folks that compiled against 6.0.2 or later and target 6.0.0 or 6.0.1 without the workaround.
  In general, since 6.0.1 and 6.0.2 are security releases, customers are encouraged to update to the latest version.

Screenshots

Before

6.0.1

6.0.2

After

A private build for this fix:

[RussKie]

Here's a test package: https://dev.azure.com/dnceng/internal/_artifacts/feed/general-testing-internal/NuGet/runtime.win-x64.Microsoft.DotNet.Wpf.GitHub/6.0.3-servicing.22110.10/

[dsplaisted]

Same comment as on the WinForms PR, using the .2 patch version should be conditioned on whether we're building for 6.0, and should not apply to 7.0 and forwards.

[batzen]

Version here must be 6.0.0.0 or simply 6.0. At least from my point of view and past experience with version pinning.

[RussKie]

Same comment as on the WinForms PR, using the .2 patch version should be conditioned on whether we're building for 6.0, and should not apply to 7.0 and forwards.

This is a 6.0 branch. For the 7.0 branch it is locked at Major.Minor.0.0, see #6099.
Is there a situation where you expect 6.0 spill into another branch?

[dotMorten]

Any applications built on 6.0.2 or later that need to target 6.0.0 or 6.0.1 will need to use the workaround provided in dotnet/core#7176. It is not ideal, but is believed to have a lesser impact than going back to 6.0.0.0 versions, and have 6.0.2 broken.

Is it really? In my mind 6.0.2 is already broken. Why can't you roll the version back to 6.0.0? We now don't have to ensure people have .NET 6 installed, but also have the very latest version of it installed. People have to change their build systems or code just to use a class library built with the latest VS.

[RussKie]

Is it really? In my mind 6.0.2 is already broken. Why can't you roll the version back to 6.0.0? We now don't have to ensure people have .NET 6 installed, but also have the very latest version of it installed. People have to change their build systems or code just to use a class library built with the latest VS.

If we roll back to 6.0.0.0 - we will have 6.0.2 release broken, and any artifacts produced against 6.0.2 will require a recompilation (app, dlls, NuGets).
If we lock at 6.0.2.0 - we prevent running 6.0.2+ artifacts on 6.0.0 and 6.0.1 releases. However both 6.0.1 and 6.0.2 are security releases, and customers (especially enterprise) are encouraged to update to the latest version, and over time we don't expect many 6.0.0 or 6.0.1 installations.
Unfortunately this is a lose-lose situation, and we're choosing the long term viability.

[dsplaisted]

@dotMorten To add to what @RussKie said:

• If we revert to the version number 6.0.0, then all DLLs built using the 6.0.2 reference assemblies will be broken. I don't think there would be any other workaround besides rebuilding, so any NuGet packages published like this would be irreversibly broken and would need to be updated.
• If we leave the version number at 6.0.2, there is a workaround that lets you build an app or library that can run on 6.0.0 or 6.0.1, documented here: Issue building with Windows Desktop 6.0.2 core#7176
• Whichever change we make, it won't be until next month's release, so by then a lot more of the runtimes should have been updated to at least 6.0.2 anyway.

So that's some of the reasoning behind why we think the least bad thing to do is to probably leave the version numbers at 6.0.2.

[RussKie]

Approved over email