Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[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?). #1944

Closed
v-sherryfan opened this issue Jan 29, 2024 · 12 comments
Assignees
Labels
area-app-model Issues pertaining to the APIs in Aspire.Hosting, e.g. DistributedApplication area-docs

Comments

@v-sherryfan
Copy link

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
image

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

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

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-app-model Issues pertaining to the APIs in Aspire.Hosting, e.g. DistributedApplication label Jan 29, 2024
@davidfowl
Copy link
Member

@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

@davidfowl davidfowl added this to the preview 3 (Feb) milestone Jan 29, 2024
@eerhardt
Copy link
Member

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
Copy link
Member

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
Copy link
Member

@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
Copy link
Member

eerhardt commented Jan 29, 2024

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
Copy link
Member

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
Copy link
Member

@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)

@eerhardt
Copy link
Member

I opened dotnet/docs-aspire#341 to get this done for preview3.

@davidfowl
Copy link
Member

Closing this as by design.

@ronaspet
Copy link

I have this issue, as well. The Nuget and workload versions are the same (8.0.0-preview.5.24201.12).

@murh-lego
Copy link

I have this issue, as well. The Nuget and workload versions are the same (8.0.0-preview.5.24201.12).

Same issue

@davidfowl
Copy link
Member

We missed this in upgrade guide for preview 5. https://learn.microsoft.com/en-us/dotnet/aspire/whats-new/preview-5?tabs=dotnet-cli#upgrade-to-preview-5

Change your project reference in the apphost from Aspire.Hosting to Aspire.Hosting.AppHost and it will work.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-app-model Issues pertaining to the APIs in Aspire.Hosting, e.g. DistributedApplication area-docs
Projects
None yet
Development

No branches or pull requests

6 participants