-
Notifications
You must be signed in to change notification settings - Fork 485
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
Comments
@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 |
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. |
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... |
Beyond, upgrading all the NuGet packages in the solution, what upgrade experience are you referring to? The workload itself? |
Users need to do both:
Is there a place we can put this documentation? Do we put it in the blog post? Somewhere on learn.microsoft.com? |
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. |
@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) |
I opened dotnet/docs-aspire#341 to get this done for preview3. |
Closing this as by design. |
I have this issue, as well. The Nuget and workload versions are the same (8.0.0-preview.5.24201.12). |
Same issue |
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. |
REGRESSION INFO: Not repro on Aspire 8.0.0-preview.2.23619.3
INSTALL STEPS
REPRO STEPS
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.
The text was updated successfully, but these errors were encountered: