Assembly version stopped being bumped with every build in 2.1.300+

[nguerrera]

MSBuild on desktop cannot load more than one version of our tasks unless we bump the assembly version. (MSBuild on coreclr can't either, but we have a 1:1 msbuild:sdk relationship on coreclr so it's moot. The current limitations on coreclr are even worse, can't load SxS in same load context regardless of version, but again moot here.)

If an MSBuild node is alive using a different build of the same Major.Minor.Patch release, then it will use targets from the new build and tasks from the old one. When there are contract changes between the tasks and targets, this can lead to confounding errors like "task X could not be loaded from Microsoft.NET.Build.Tasks.dll" or "task Y does not take parameter Z".

We got around this in the past by bumping the assembly version with every build. Since tasks are always dynamically loaded and never referenced directly at compilation time, this doesn't have the usual negative consequences of requiring excessive binding redirects, etc.

This has a history of regressing with infrastructure (repo toolset, arcade, etc.,) because the infrastructure is opinionated that the build number should not be part of the assembly version, which makes sense for most things, but not build tasks. We need to add test coverage to stop this from regressing. It can go a long time unreported because 1) things might still work when mixing tasks and targets between builds and 2) msbuild nodes eventually shut down and things start working again, letting the problem get chalked up to flakiness that can't be reproduced.

Now, with the move to build-to-build upgrades of patches, dotnet/installer#530, I think there will be a prompt to terminate users of older build or a prompt to reboot following the upgrade.That would mitigate this, but we should still be defensive for forced SxS patch installs (via .zip or whatever).

[nguerrera]

Setting milestone optimistically to 2.1.5xx as I think that's the baseline of builds still being patched that have this problem. But we can discuss the bar and where we'd actually like to take the fix. We have to be careful as different infrastructure in different branches may require different fixes.

[nguerrera]

The chances of these errors vs. silently using older tasks are much higher in preview-to-preview build-to-build upgrades. Once we are servicing, we don't tend to make many changes to the task dll, and probably never make breaking changes to it.

[johnbeisner]

The 'FilesInUse' functionality of the SDK bundle installer seems to work as it should:

    <BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.Foundation">
      <bal:WixStandardBootstrapperApplication
        LicenseFile="dummyeula.rtf"
        ShowFilesInUse="yes"
        ShowVersion="yes" />

Example:

[nguerrera]

I'll fix this now.