[WebToolsE2E][Aspire] After installing both aspire9 and aspire8, creating aspire-starter-8 fails with error: "The constraint 'workload' failed to initialize ..."

[v-sherryfan]

REPRO STEPS

1. Install SDK 9.0 RC2
2. Install Aspire 9.0 template -latest version 9.0.0-rc.1.24511.1
   • Add dotnet8 feed
   • dotnet new install Aspire.ProjectTemplates::9.0.0-rc.1.24511.1 --force
3. Now If you try to create aspire--starter-8 project, you will see another issue #6263
4. Install Aspire 8.2.1 workload
   • dotnet workload update
   • dotnet workload install aspire
5. Create aspire-starter-8 project again

ACTUAL

• After installing aspire8 workload, creating aspire-starter-8 project still fails

  

• According to the error details, run dotnet new aspire-starter-8 -o aspire09 --force

  

EXPECTED

Create aspire-starter-8 project successfully

[davidfowl]

Came here to file this issue. I removed the 8 workload and I get a ton of errors installing the new templates for 9 rc1

[v-elenafeng]

On my machine with "VS 17.12 P3 (Without Aspire 8.2.0) + Aspire 9", I modified the VS installer and checked the .NET Aspire SDK.

Creating 8.0 aspire app by running 'dotnet new aspire-starter-8'

Tried again using the command 'dotnet new aspire-starter-8', it worked this time.

Tried some more times, aspire09 worked.

[mitchdenny]

That would have worked because when you installed the .NET Aspire SDK as part of VS it would have installed the .NET Aspire 8.0 workload. You can probably confirm this with dotnet workload list.

[joperezr]

@davidfowl

Came here to file this issue. I removed the 8 workload and I get a ton of errors installing the new templates for 9 rc1

Those are not errors, they are just messages saying that some of the templates you are installing will not be available given they depend on the workload and you don't have it installed. I understand how this message can be confusing, but this is expected and the right behavior as we don't want those templates to show if you don't have the workload installed.

[joperezr]

As for this issue and the problem that @v-elenafeng is hitting, it is due to this templating issue: dotnet/templating#7946

That issue describes a race condition that is happening in the template loading engine when trying to resolve which workloads are installed in order to find out if the constraints on the templates are satisfied or not. This only happens to our downlevel templates (i.e. aspire-starter-8) because those are the only ones that have a constraint to only work in case the workload is installed. Since this is a race condition, it will fail some times and work other times, like @v-elenafeng found above. I chatted about this issue with @marcpopMSFT and @dsplaisted who own the template engine but unfortunately it looks like the fix is not trivial here.

[marcpopMSFT]

I don't think the warning showing up is related to the race condition bug that we have but rather the template engine constraint feature appears to not expect you to have a valid template and a constrained template in the same package. We should probably suppress that message when not targeting the template that has the constraint.

Is that what v-elenafeng is reporting? I also see a report above that sometimes it works and sometimes it doesn't which I guess would point to the race condition but we were getting a very different error experience before. CC @baronfel

[joperezr]

No, the warning regarding the templates was just a comment from @davidfowl which as you pointed out is just expected. The original issue getting reported here by @v-elenafeng is the duplicate issue we've talked about this past week. If you go to the top post and look at the first screenshot in the Actual section you'll see how we are failing to create the project due to the duplicate manifest thing.

[marcpopMSFT]

Ahh got it now. I was thinking we'd see the access violation but that's a different result from the same issue. @dsplaisted we discuss potentially handling the duplicate situation better before we realized this was a parallelization issue. We could potentially still work around this by making that original proposed fix (which was to not report the duplicate if they were the exact same file loaded twice). Thoughts?

[dsplaisted]

If we want to make a simple-ish fix, I would try to update WorkloadConstraintFactory to put the equivalent of a lock around the GetInstalledWorkloadsAsync call.

[joperezr]

We should verify if this still repros after the consolidated templates.

[balachir]

@joperezr this issue itself does not apply anymore with the change to Aspire 9 templates in GA. Do we need to still need to keep this issue open to track the fix for workload constraints in the sdk? Or perhaps open a separate issue in the sdk repo to track that?

[joperezr]

No need to keep this open, as templating already has an issue tracking the fix for this: dotnet/templating#7946

Closing this as not applicable for Aspire any longer.