Use Aspire 8.0 workload in the 9.0 SDK #41562
Conversation
ghost
added
|
@joperezr any customer who keeps an older preview installed will be broken for aspire, correct? If so, we'll probably want to either breaking change or relnote this so that there's a place to point customers to tell them to uninstall their old sdk. Would it be worth detecting that a 9.0 aspire manifest is installed (any way to do that?) and provide a warning to help customers unwind this? |
|
Wouldn't installing a newer preview of the SDK replace a previous installation? (and therefore remove the 9.0 manifest) If so I'm fine with doing a relnote to basically just tell customers that if they want to use Aspire they should just install latest 9.0 SDK |
|
We only replace the earlier version on windows admin installs. Zip installs and mac/linux installs would not replace the prior version. We've definitely run into problems of people having months old previews still installed fwiw. |
|
/azp run sdk-source-build,sdk-unified-build |
|
Azure Pipelines successfully started running 2 pipeline(s). |
I see, in those cases I think we can suggest either uninstalling manually or alternatively using rollback files (which is the current workaround we advertise to folks using the 9.0 SDK) to force the use of the 8.0 workload as opposed to newer manifests. |
|
That's a reasonable approach. I just wanted to ensure there was documentation we could point people at. Remerging as the vmr builds were having issues and let's see if that helps. |
|
@marcpopMSFT trying to understand the source build failures but not sure I'm following what the issue is. Do you have any clue or do you know who can I work with to resolve? I'd really like this to ship in Preview 6 and I know snap is soon. |
@dotnet/source-build-internal and @dotnet/product-construction for the source build and VMR failures. Looks like a similar failure in both around merged manifests and not sure how that's related to this PR: |
|
The error is about how the manifest produced by aspire's publishing doesn't have the same root attributes as the other repos. Because you rolled the aspire sha back to an older 8.0 version, it's highly likely that it's missing some fixes that were made in mian to work with the VMR. |
|
I see, is there a way to know which fixes are those? Aspire builds with the 8.0 arcade, so if the fixes are done in arcade main then that would explain it. |
|
/backport to release/9.0.1xx-preview6 |
|
Started backporting to release/9.0.1xx-preview6: https://github.com/dotnet/sdk/actions/runs/9667085593 |
|
/azp run sdk-unified-build |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Looks like this is ready to go @marcpopMSFT 🙂 |
4 participants
cc: @dsplaisted @marcpopMSFT @baronfel
This change is making it so that the 9.0 SDK will have an 8.0 Aspire workload, as opposed to the 9.0 previews that it had before. Aspire decided to not have 9.0 previews and instead only maintain a single stable 8.0 train, so given this decision, this change will make it so the SDK will carry the latest 8.0 workload as opposed to a dead-ended 9.0 preview one.
We have validated that this will still allow users to use the 9.0 SDK to build Aspire apps, even if they are targeting 9.0 TFMs in their individual services. After this change ships, we'll be able to un-list all of the (now dead-ended) 9.0 preview packages for Aspire workloads, in favor of pushing folks to use to the live 8.0 train.