Fix 3.0/3.1 targeting pack servicing skip infrastructure to allow for prerelease servicing builds

[dagood]

This infra only activates for stable builds:

https://github.com/dotnet/core-setup/blob/9898068272cde5d004dec24e2fcabf9f4565ce9b/eng/Versions.props#L39-L43

The original intent was to avoid applying this during pre-GA preview builds, where we always want to publish a new targeting pack.

However, we want to apply the infra while building prerelease-versioned servicing builds as well (e.g. 3.1.1-servicing.19576.4) so that they keep using the previously released stable build.

Until then, we need to go back to pinning.

See discussion: dotnet/installer#5814 (comment)

[dagood]

Note that we should fix the infra in 3.0/3.1, but the solution should also be applied to master here in dotnet/runtime and also in dotnet/windowsdesktop.

[dagood]

@NikolaMilosavljevic @nguerrera @wtgodbe @mmitche @MichaelSimons

I think the right fix is remove the condition entirely from the settings.

-  <ItemGroup Condition="'$(StabilizePackageVersion)' == 'true'">
+  <ItemGroup>
     <ProjectServicingConfiguration Include="Microsoft.NETCore.App.Ref" PatchVersion="0" />
     <ProjectServicingConfiguration Include="NETStandard.Library.Ref" PatchVersion="0" />
   </ItemGroup>

With this:

• During master builds, patch version for Microsoft.NETCore.App is always 0, so it gets built.
• When release/5.0 forks, patch stays 0, so it keeps getting built.
  • After releasing 5.0.0, version advances to 5.0.1, and optionally becomes 5.0.1-servicing-12345. This disables the targeting pack build due to the patch version not matching, as desired.
  • Enabling it is same as always, set PatchVersion="1" to make it match

---

NETStandard is harder to think about because ideally it wouldn't be in this repo in the first place. Right now:

• dotnet/runtime master produces 2.1.0-alpha-...
• dotnet/core-setup release/3.0 is set up to produce 2.1.1 (disabled by PatchVersion="0")
• dotnet/core-setup release/3.1 is set up to produce 2.1.1 (disabled by PatchVersion="0")

It's strange that dotnet/runtime master is producing new NETStandard 2.1.0-alpha targeting packs, even though 2.1.0 is already released.

I would argue that dotnet/runtime master should be set up to produce NETStandard 2.1.1, 2.2.0, or nothing at all. We can also set it up as 2.2.0 but still disable it using PatchVersion="N/A".

[dagood]

Fixed in dotnet/runtime for 5.0+ by #2291.
core-setup 3.0: dotnet/core-setup#8991
Fixed in core-setup 3.1: dotnet/core-setup#8992

I've opened #2294 to independently decide whether to keep building NETStandard in master.