[release/6.0] Always build App.Ref and the targeting packs

[dougbu]

[release/6.0] Always build App.Ref and the targeting packs

• remove $(IsTargetingPackBuilding) entirely
• 6.0.x version of Always build App.Ref and the targeting packs #39568

Description

Remove $(IsTargetingPackBuilding) settings and remove all use of the property. For example, it's not necessary to reference Microsoft.AspNetCore.App.Runtime.csproj when Microsoft.AspNetCore.App.Ref.csproj won't build; references to Microsoft.AspNetCore.App.Ref.csproj are all we need.

In detail:

• where Conditions were positive ($(IsTargetingPackBuilding) or $(IsTargetingPackBuilding)' == 'true'), remove the Condition or its relevant portion
• otherwise, (! $(IsTargetingPackBuilding) or $(IsTargetingPackBuilding)' != 'true'), remove the affected block or the relevant portion of the Condition

nit: simplify any leftover Conditions if possible

Fixes #39471

Customer Impact

Without this change, we're unable to create source-build tarballs except with significant hacks.

We also realized skipping builds of the …Ref packages and targeting pack installers would be uncommon given their new analyzer and code generator content in 6.0.x. Decided always building these assets simplified everything in the relevant repos.

In this repo, not releasing the targeting packs was a major exception. We build and pack everything else for every release and have since 3.1.0.

Regression?

• Yes
• No

The main difference from 5.0.x in this release is the analyzer and code generator assemblies in our targeting packs. This content makes it easier to justify building the targeting packs for every release.

Risk

• High
• Medium
• Low

This PR removes some complexity from our build and should simplify our release process.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

This PR does not change individual packages. It just ensures Microsoft.AspNetCore.App.Ref.nupkg and our targeting pack installers are always created.

---

When servicing release/2.1

• Make necessary changes in eng/PatchConfig.props

[ghost]

Hi @dougbu. If this is not a tell-mode PR, please make sure to follow the instructions laid out in the servicing process document.
Otherwise, please add tell-mode label.

[dougbu]

@Pilchie should we treat this one as ask-mode due to the release implications i.e. shipping more❔

[Pilchie]

I can bring it up in Tactics tomorrow.

[dougbu]

I can bring it up in Tactics tomorrow.

Thanks @Pilchie. I added the servicing template to the description.

[ghost]

Hi @dougbu. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

[leecow]

Need to confirm we're doing the right thing on update and uninstall.

[dougbu]

Rebased on brecon/60cookie to confirm continued success

[TanayParikh]

@dougbu can this be merged now given the CI is passing and it is servicing approved?

[wtgodbe]

Closing in favor of #39924

[dougbu]

can this be merged now given the CI is passing and it is servicing approved?

@TanayParikh /fyi what @wtgodbe did is a bit cleaner because the change will go in together w/ the new branding. We considered force-merging the branding PRs then doing these but either works. And both are better than doing a lot of stuff before branding is done.