[WebToolsE2E][Aspire] Open an existing aspire 8.0 P1 project and build the solution, there is an error: The type or namespace name 'Projects' could not be found (are you missing a using directive or an assembly reference?).

[v-sherryfan]

REGRESSION INFO: Not repro on Aspire 8.0.0-preview.2.23619.3

INSTALL STEPS

1. Clean machine: Win11 x64 23h2 ENU
2. Install VS 17.10.0 Preview 1.0 [34528.15.main]
3. Install .NET SDK 8.0.200
4. Install Aspire Preview 3 latest build 8.0.0-preview.3.24078.5
5. Apply NuGet Feeds

REPRO STEPS

1. On Aspire template version 8.0.0-preview.1.23557.2, Open VS, create a new project > ASP.NET Core Web App (Razor Pages) > give a name 'RazorWithAspire' > .NET 8.0 > check 'Enlist in .NET Aspire orchestration' > Create. Or you can open existing aspire 8.0 P1 project.
2. Update Aspire template version to latest 8.0.0-preview.3.24078.5
3. Open existing Aspire 8.0 P1 project 'RazorWithAspire'
4. Build solution

ACTUAL
Open existing Aspire 8.0 P1 project and build solution

The type or namespace name 'Projects' could not be found (are you missing a using directive or an assembly reference?)

EXPECTED
If you manually update 'Aspire.Hosting' to the latest 8.0.0-preview.3.24078.5, the error will disappear.

[davidfowl]

@eerhardt This is due to the project reference changes. Should we issue a warning about the package version? I mentioned that we should document this as part of the upgrade experience.

cc @IEvangelist

[eerhardt]

The dashboard is going to be in a similar situation if you mismatch workload and NuGet package reference. For example if you update your NuGet package reference without updating to the new workload.

Are we sure we want to continue having both? It just seems like a recipe for failure.

[davidfowl]

Yes, absolutely. Until we get the ability to pin workload versions, a mismatch is the worst case scenario when breaking changes are made. We have a version check for DCP in Aspire.Hosting for runtime mismatches. This one is a bit tricker...

[IEvangelist]

@eerhardt This is due to the project reference changes. Should we issue a warning about the package version? I mentioned that we should document this as part of the upgrade experience.

cc @IEvangelist

Beyond, upgrading all the NuGet packages in the solution, what upgrade experience are you referring to? The workload itself?

[eerhardt]

Beyond, upgrading all the NuGet packages in the solution, what upgrade experience are you referring to? The workload itself?

Users need to do both:

1. Upgrade the workload
2. Update the NuGet package versions to match

Is there a place we can put this documentation? Do we put it in the blog post? Somewhere on learn.microsoft.com?

[eerhardt]

In discussion yesterday, we decided that the "workload sets" feature coming in the .NET SDK will allow us to put the Aspire version being used in the app in source control. See dotnet/designs#294 for more info.

For preview3, I propose that we document that you need to update both the aspire workload + all NuGet packages when updating. We don't support mixing and matching preview versions.

For GA, I think we should move the aspire version to a single place (the workload sets), and no longer require a manual PackageReference to Aspire.Hosting in the AppHost.csproj.

[davidfowl]

@eerhardt I agree with the preview3 solution.

For GA we can discuss the user experience for library authors so we get a better understanding what it means to get rid of the package reference.

Let’s file a doc issue so we remember to document this as part of the upgrade. We’ll also make sure it’s in the blog post (cc @samsp-msft)