[release/6.0] Fix VS component versions

[joeloff]

This update contains multiple fixes for issues that were identified during the last servicing release.

• ItemDefinitionGroup is evaluated globally while the FileVersion property is only set after the GetAssemblyVersion target runs. This causes the VS components to assume the default workload version, which doesn't play well with upgrades in VS. The assembly file version value is preferred because it can change between builds, allow consecutive insertions into VS that can be upgraded.
• The updated task now provides metadata that will allow us to split the VSDROP generation into two separate archives. One which only contains workload packs (needed to share DROPs across VS versions to support multi-targeting) and another that only contains the manifest installers and workload components.
• The ZIP archive names have been updated to disambiguate its contents and support automatic drop creation during staging.

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

ItemDefinitionGroup is evaluated globally while the FileVersion property is only set after the GetAssemblyVersion target runs. This causes the VS components to assume the default workload version, which doesn't play well with upgrades in VS. The assembly file version value is preferred because it can change between builds, allow consecutive insertions into VS that can be upgraded.

Author:	joeloff
Assignees:	joeloff
Labels:	area-Infrastructure-libraries
Milestone:	-

[joeloff]

We don't need this until the next servicing release as we can fix this up manually when we publish to VS.

[hoyosjs]

@carlossanlop Let's hold this one for 6.0.10

[ghost]

Tagging subscribers to this area: @directhex
See info in area-owners.md if you want to be subscribed.

Issue Details

---

ItemDefinitionGroup is evaluated globally while the FileVersion property is only set after the GetAssemblyVersion target runs. This causes the VS components to assume the default workload version, which doesn't play well with upgrades in VS. The assembly file version value is preferred because it can change between builds, allow consecutive insertions into VS that can be upgraded.

Author:	joeloff
Assignees:	joeloff
Labels:	NO-MERGE, area-Infrastructure-libraries, area-Infrastructure-mono
Milestone:	6.0.x

[lewing]

Is there any reason not to do the 7.0 version of this now?

[joeloff]

Is there any reason not to do the 7.0 version of this now?

None that I can think of

[joeloff]

I'm going to continue pushing more of the 6.0 changes here so we can get everything ready in one go

[carlossanlop]

I'm going to continue pushing more of the 6.0 changes here so we can get everything ready in one go

Hope you don't mind if I convert it to draft.

[joeloff]

This PR is blocked on dotnet/arcade#10582 We likely need to update it to include the Arcade changes once we have a validation build.

Below is an example of what the new archives will look like

[joeloff]

@hoyosjs can you take another look at the PR. The darc update dependencies touched a bunch of Arcade related files.

[hoyosjs]

The changes LGTM.

[lewing]

ci is blocked on #75294

[hoyosjs]

And it broke :( This will likely need #68847

[lewing]

tell mode packaging fix