devcontainers
`dotnet` image throws warning about stale workloads
Everytime I build a .NET project using the .NET SDK in the devcontainers/dotnet image, I get the same error message:
An issue was encountered verifying workloads. For more information, run "dotnet workload update".
This error message leads me to believe that the workloads on the SDK are stale in some way. I've tried running the mentioned command in the devcontainer's lifecycle, but it doesn't always consistently clear the error message. Is this something that can be fixed in the base image or is there a specific lifecycle step where I should run dotnet workload update.
Here's related issues in the .NET repositories:
- dotnet/sdk#46187
- dotnet/installer#12104
Hello @seesharprun
Thank you for raising the issue.
Could you please share the few more details on devcontainer.json and dotnet image and your project sample setup to reproduce the issue.
This happens to me any time I use this image in a devcontainer, but you can see a running example by opening this repo in GitHub Codespaces:
https://github.com/azurecosmosdb/quickstart-nosql-dotnet
Devcontainer: https://github.com/AzureCosmosDB/quickstart-nosql-dotnet/blob/main/.devcontainer/devcontainer.json#L2
Thank you. I could repro the issue.
But i do not get it everytime i run the build command. I could see the warning message the first time i run the dotnet buildcommand.
If i run the dotnet build command again I could not see the issue. And also When i run the sudo dotnet build command it works even the first time without issues.
Checking on this further. Will update you after completing the analysis.
Thanks! I tried to fix this by running dotnet workloads update as part of the container's lifecycle so it was pre-baked, but that didn't always consistently work.
I'm not against running dotnet build whenever the container starts, but it would be great if there was a best practice here or a way to prevent the warning.
Bump, happens to me every time as well, running sudo dotnet workloads update seems to help but that's more time in my container build time I'd rather not take.
