-
Notifications
You must be signed in to change notification settings - Fork 417
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
Breaking change in 8.2.0 .NET Aspire Workload #5501
Comments
What does this mean? Will the workload be deprecated come 9.0? It always felt weird how I had to tell everyone to write this random line in the CLI (one that nobody has ever heard of; "dotnet workloads? What's that?") just to run what otherwise looks to be a standard .Net app. Other than "create, build and run", what other things does it do? Creating the Manifest? Publishing via AZD? |
The plan is that for 9.x, the workload will mostly only contain the .NET Aspire template packs, so by installing it, main benefit will be that you will have our templates installed (and updated) automatically for you. That said, you will still be able to manually install the templates using the install CLI command ( |
Updated the top post to introduce a new preferred workaround ( |
Still unable to build.
|
@Kralizek did you run dotnet workload update? |
yes.
Also tried with --no-cache an uninstalling and installing the workloads SDK updated via winget and also via visual studio installer. |
What nuget feeds do you have configured |
|
@Kralizek This issue details how to avoid/delay the 8.2.0 update. Did you perform those steps and then try to update to 8.2.0? |
no, updated directly to 8.2.0. |
yes, I use this one in the roots of all my projects to avoid accidental upgrade to previews cat .\global.json
{
"sdk": {
"version": "8.0.0",
"rollForward": "latestMinor"
}
} PS: build server works fine, it's my local machine that refuses to build. |
Run the workload update outside of the global.json context. |
same same
|
@Kralizek I know what is going on here. You have the opposite problem that this issue is tracking: you have the Aspire 8.1.0 workload installed, and your project is referencing 8.2.0. For 8.2.0 to build correctly, we need both workload and package reference to match. The reason why you are still in 8.1.0 of the workload even after running |
it worked like a charm! thanks @joperezr and @davidfowl for the help :) Here is the updated workload list
|
@Kralizek did you know you opted into workload sets? |
I'm glad we were able to unblock you. I have edited the top post to also cover this scenario, and posted the solution in there too for folks that run into this. |
I didn't know it. I have no idea how I did it. I suspect it happene when I tried to install the workload doing |
I want to share my experience upgrading to 8.2.0 so far. It hasn't been great, but I appreciate the efforts to improve it. We used Knowing that this would prevent us from working on future stories and even publishing a new version of our project, we quickly updated all references to 8.2.0. Later, we found a regression and spent extra time finding a workaround. After some time, we decided to roll back to 8.1.0. We learned about workload rollback files, which we'll use from now on. I love that the new workload set works with {
"sdk": {
"version": "8.0.401",
"rollForward": "latestPatch",
"allowPrerelease": false,
"workloadVersion": "8.0.401" // ???
}
} We're using // custom regex manager
{
"description": ".NET Aspire workload rollback file (https://github.com/dotnet/aspire/discussions/2230)",
"customType": "regex",
"fileMatch": ["^rollback.json$"],
"matchStringsStrategy": "any",
"matchStrings": [
"\"microsoft.net.sdk.aspire\":\\s*\"(?<currentValue>[^/]+)/[^\"]+\"" // matches 8.1.0/8.0.100 for instance
],
"datasourceTemplate": "nuget",
"versioningTemplate": "nuget",
"depNameTemplate": "Aspire.Hosting.AppHost"
} We're using .NET Aspire in a non-conventional way. We ship it as part of a cross-platform CLI tool, which could be considered like Tye but tailored for our local DX needs. We install the .NET Aspire workload as part of our CI/CD pipeline, so it will be more resilient from now on. We didn't want our developers (especially non-.NET developers) to deal with workloads, so our CLI tool directly downloads the proper workload package from NuGet at runtime. We use reflection to modify the DCP options and override any DCP and dashboard paths set in the assembly metadata. Our tool uses .NET Aspire as the main orchestrator, and it's been our solution for helping developers working in a distributed environment with many services, many repos, and many teams working with different languages. Our tool does much more than that, including generating self-signed certificates using mkcert, allowing developers to use custom domains, automatic hosts file maintenance, and automating certificate authority sync for containers to seamlessly trust any self-signed host certificate (mkcert and ASP.NET Core dev cert). |
Yep that's it. Running |
|
I have the Aspire 8.1.0 workload installed, and and I'm trying to udate the workload to 8.2. ❯ dotnet workload config --update-mode manifests Advertising manifest not updated. Manifest package for microsoft.net.sdk.android doesn't exist. Successfully updated workload(s): android aspire ios maccatalyst maui-windows. ❯ dotnet workload list Installed Workload Id Manifest Version Installation Sourceandroid 34.0.113/8.0.100 SDK 8.0.400, VS 17.11.35222.181 I don't understand why it says that the source is SDK 8.0.400. I have 8.0.401 installed ❯ dotnet sdk check .NET SDKs: Version Status8.0.400 Patch 8.0.401 is available. |
My project references 8.2.0 and I also tried to opt-out of workload-set mode by running Workload update failed: One or more errors occurred.
(Version 34.0.130 of package microsoft.android.sdk.windows.msi.x64 is not found in NuGet feeds...) What worked for me:I got the build running after installing the latest VS preview version: Then from the project directory, ran: dotnet workload restore
dotnet workload update Then restarted VS and rebuild was successful. |
@Emil-Granbom can you try using the full nuget org feed url to see if that works? |
@teresaqhoang it looks like your dotnet cli is aware of some package versions that are only available in our dogfooding feeds for some other workloads (might have happened if you build other dotnet repos in the same machine). To fix the error you are hitting, you can try adding this feed to find the package it is complaining about: |
@joperezr That was it! Thanks a lot. |
This was exactly it. Thank you @joperezr! |
Our CI pipeline failed in relation. We are using .net 8 tooling with aspire packages specified to 8.1. I am able to use the workaround. We never previously ran any --version commands manually. Our CI pipeline was running 'dotnet workload restore' and is now using 'dotnet workload install aspire --version 8.0.401' along w/ the csproj SkipAddAspireDefaultReferences flag. |
I had tried everything already mentioned (and refresh/restart/etc.) until running the following
|
ok i have it working there is nuget authorization issue with private package, open your project, right click open in terminal close visual studio, re-open |
Issue building projects referencing 8.1.0 when having 8.2.0 workload installed
As part of our work of removing the requirement for installing the .NET Aspire workload in order to create, build and run .NET Aspire projects in 9.0, we made some significant changes in 8.2.0 which, when installed, will require your AppHost projects to also be updated and reference the 8.2.0 version of the
Aspire.Hosting.AppHost
package. For people that are hitting issues, our recommendation is to update to 8.2.0 by making sure that your AppHost projects have the following:We also understand that some people may not be able to update to 8.2.0 immediately, so here are three workarounds to ensure you can continue to build and run your .NET Aspire 8.1.0 projects by either adding some code into your AppHost project, or by "pinning" the version of the .NET Aspire Workload you use to 8.1.0.
Workaround 1: Add the following lines to your AppHost Project file
If you are unable to update to 8.2.0 immediately, you can add the following lines to your AppHost project file to ensure that you are able to continue to build it.
Please make sure to delete these lines as soon as you are able to update your references to 8.2.0 or later version.
Workaround 2: If you are using SDK 8.0.400 or later
If you are using SDK 8.0.400 or later, you can pin the version of the .NET Aspire workload to 8.1.0 by using the new workload-set feature by running the following command:
This will ensure that the .NET Aspire workload that you use, will be the one that comes with the 8.0.401 workload-set, which is the 8.1.0 version.
Workaround 3: If you are using an older SDK
Workload-sets are a new feature, so if you are using an older SDK, the above workaround won't work for you. You can still pin the version of the .NET Aspire workload to 8.1.0 by making use of rollback files, and here is how you can do that:
rollback.json
with the following content:rollback.json
file is located:This will ensure that the .NET Aspire workload that you use, will be the 8.1.0 version, which will allow you to continue to reference the 8.1.0 version of the
Aspire.Hosting.AppHost
package in your AppHost projects.We apologize for the inconvenience this may have caused and we are working on providing a better experience by removing the requirement for installing the .NET Aspire workload in order to create, build and run .NET Aspire projects in 9.0.
Issue building projects referencing 8.2.0 when having 8.1.0 workload installed
If you are trying to build and get an error like:
It means that you need to install a newer version of the workload in order to build the project. As the error suggests, you can do so by running
dotnet workload update
. If you have tried runningdotnet workload update
but you keep having this error in your build, make sure that you:https://api.nuget.org/v3/index.json
as one of your sources when runningdotnet nuget list source
. If you don't see it, you can add it by runningdotnet nuget add source "https://api.nuget.org/v3/index.json"
.dotnet workload update
, you will remain pinned to the version you have currently. In order to allow upgrading the Aspire workload, you can opt-out of workload-set mode by runningdotnet workload config --update-mode manifests
, which would then allow to install the version of .NET Aspire you need by simply runningdotnet workload update
again.The text was updated successfully, but these errors were encountered: