Stabilize upgrade codes for host msi

[NikolaMilosavljevic]

Stable upgrade codes and dependency key to allow proper msi upgrade experience.

We are using values from latest official release (6.0.0).

[joeloff]

We should probably look at the dependency provider key and figure out what to do. Below is from RC2 and RTM. When upgrading, we need to ensure stable key so that chainer dependencies can be maintained, otherwise we risk losing the ref count against the MSI itself.

[NikolaMilosavljevic]

We should probably look at the dependency provider key and figure out what to do. Below is from RC2 and RTM. When upgrading, we need to ensure stable key so that chainer dependencies can be maintained, otherwise we risk losing the ref count against the MSI itself.

Thanks. I'm going to see what the best option is to override the auto-generated values.

[joeloff]

We should probably look at the dependency provider key and figure out what to do. Below is from RC2 and RTM. When upgrading, we need to ensure stable key so that chainer dependencies can be maintained, otherwise we risk losing the ref count against the MSI itself.

Thanks. I'm going to see what the best option is to override the auto-generated values.
Something like Dotnet_CLI_SharedHost,$(MajorVersion).$(MinorVersion),$(Platform) should work (or whatever the relevant properties are). The tricky bit is whether we decide to leave the older versions or if we allow them to upgrade, allow the ref count to become inaccurate as part of the transition.

[NikolaMilosavljevic]

We should probably look at the dependency provider key and figure out what to do. Below is from RC2 and RTM. When upgrading, we need to ensure stable key so that chainer dependencies can be maintained, otherwise we risk losing the ref count against the MSI itself.

Thanks. I'm going to see what the best option is to override the auto-generated values.
Something like Dotnet_CLI_SharedHost,$(MajorVersion).$(MinorVersion),$(Platform) should work (or whatever the relevant properties are). The tricky bit is whether we decide to leave the older versions or if we allow them to upgrade, allow the ref count to become inaccurate as part of the transition.

I was thinking of allowing override of ProviderKey value, which works in my tests and is in my new Arcade PR: dotnet/arcade#8181

[NikolaMilosavljevic]

I've pushed the new change to stabilize ProviderKey value by overriding the Candle variable.

[NikolaMilosavljevic]

I've pushed the new change to stabilize ProviderKey value by overriding the Candle variable.

Will also need to update a reference to Arcade's Installers package once Arcade PR is approved and we get a build: dotnet/arcade#8181

[NikolaMilosavljevic]

I've updated the Arcade package (Microsoft.DotNet.Build.Tasks.Installers). This PR can now be merged, once I get the approving review and it finishes building.

[safern]

@danmoseley is this approved to merge for this servicing?

[NikolaMilosavljevic]

This test failure seems to be a known issue, that is breaking other servicing PRs: #61636

[NikolaMilosavljevic]

@danmoseley is this approved to merge for this servicing?

This is all part of the same setup work, for 6.0, 5.0 and 3.1. Here are few other examples:
#61619
dotnet/arcade#8181
dotnet/arcade#8174

[safern]

Test failure is: #61636