[release/3.1] Don't use baseline assembly versions for RID-agnostic packages

[wtgodbe]

3.1 port of #17969

In all CI builds except Windows x64, we set OnlyPackPlatformSpecificPackages=true: https://github.com/aspnet/AspNetCore/blob/e6af4bfe7e022e2c3b32c583b280965041c3d15c/.azure/pipelines/ci.yml#L254-L261

This makes us decide that all libraries without RuntimeIdentifiers are not packable: https://github.com/aspnet/AspNetCore/blob/1ff3e7b21ea5270b832a6e05c74b1b5f67d4cfb0/Directory.Build.targets#L5

Then later, we say that everything that is not packable, is not part of "this patch" (if we're doing a patch build): https://github.com/aspnet/AspNetCore/blob/1ff3e7b21ea5270b832a6e05c74b1b5f67d4cfb0/Directory.Build.targets#L62-L68

Which causes us to use basline assembly versions:

https://github.com/aspnet/AspNetCore/blob/1ff3e7b21ea5270b832a6e05c74b1b5f67d4cfb0/Directory.Build.targets#L74-L77

We are incorrect to say that these libraries/packages aren't "in this patch" - we're just not building them right now. Moving the condition for OnlyPackPlatformSpecificPackages down in the file should fix the issue. Without this, all of our non-Windows-x64 builds create runtime packs w/ 3.0.0.0 assembly versioned .dll's.

@JunTaoLuo @Pilchie @dagood @dougbu PTAL

[dougbu]

See my comments in #17969

[dougbu]

@wtgodbe am I correct you're waiting to resolve questions in #17969 before turning to this one?

[wtgodbe]

This was approved for 3.1.2 - see #17969

[wtgodbe]

Watching https://dev.azure.com/dnceng/public/_build/results?buildId=476946 to see if the test failures are unique to this PR

[wtgodbe]

Hmmm - this might not be needed in 3.1. I just looked at the runtime packs for 3.1.1, and they don't exhibit the same symptom as the 3.0.2 runtime pack (that is, all AssemblyVersions are correct at 3.1.1.0, where in 3.0.2, the non-x64 runtime packs all have AssemblyVersions 3.0.0.0). Will investigate why this is the case tomorrow.

[vivmishra]

Moved to Mar as per Tactics. Will need to be explicitly approved for Feb, if required.

[wtgodbe]

Confirmed locally that this fixes the assembly versions. The Helix failures are not new, see https://dev.azure.com/dnceng/public/_build/results?buildId=476946&view=ms.vss-test-web.build-test-results-tab (note than I ran this PR's Helix tests 4 times, resulting in the 1163 failures, which is almost exactly 291 * 4). I tried to remove the IsPackageInThisPatch concept entirely, but it gave errors that I'm not confident in the fix to - considering punting that improvement to March given the high bar for the Feb release - @dougbu thoughts?

[dougbu]

considering punting that improvement to March given the high bar for the Feb release

Agreed

[dougbu]

@Pilchie how do we ask for this to be approved for Feb.?

[dougbu]

(if it's more than the list you emailed around 😈)

[wtgodbe]

Worth noting that the original bug here is a bit mysterious - it seems that all projects with netstandard configurations are affected, but we haven't been able to get those projects to build correctly by removing their netstandard configurations. A follow up here should be to investigate why that was the case. It seems that the _InitializeAssemblyVersion target in Arcade is returning both an AssemblyVersion and FileVersion for the unaffected projects, while only returning a FileVersion for the affected projects. Our default AssemblyVersion is incorrect, the one from the target is correct.

https://github.com/dotnet/arcade/blob/d4a1ce6278134f5dc25843e228d0498203031e61/src/Microsoft.DotNet.Arcade.Sdk/tools/Version.targets#L14