Breakage with workload installation in SDK 6.0.400 #27109
Comments
dotnet-issue-labeler
bot
added
Area-Workloads
untriaged
|
I can reproduce it:
Output: |
|
cc @dsplaisted |
filipnavara
changed the title
|
I tried the repro steps on Windows and it worked OK. @marcpopMSFT, could someone with a Mac try reproing this? |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
filipnavara
changed the title
This comment was marked as outdated.
This comment was marked as outdated.
|
Ah, I figured it out... I reversed some of the steps in the instructions. I can reproduce it again. The key is to run |
|
Reduced repro on macOS. Install SDK 6.0.400 and run Observe that the |
|
Yes, Instead of using |
The original issue was observed on CI machines where the .NET SDK and workload setup was done as part of the workflow/pipeline. That's why it didn't use the global.json file and that worked in 6.0.3xx SDKs. Specifically in our case we needed it only in some cases where we didn't even want to force the SDK version but it happened to be necessary to workaround other bug. |
|
--sdk-version was really never meant to be used as your using it I don't think. I think we created it to enable VSMac scenarios and that's why it's hidden. I definitely recommend using global.json instead. Out of curiosity, are you using sdk-version to install workloads into a different SDK (which global.json would be better for) or install different workloads into the current sdk (which rollback would be better for)? |
To install workloads for specific SDK band. I cannot use global.json for our use case. We have a mix of old style xamarin.ios TFM projects that reference multi-TFM shared library .csproj. Since legacy Xamarin projects have to run with "desktop" MSBuild I get into an untested scenario that was broken since 6.0.300 band (and reported in #25651). When we actually build the The scenario with setting up CI machines without having access to global.json is quite common and creating it only to install the correct workloads seems like quite a hassle given that there was a command line option (which actually worked before!). |
|
Also, it apparently behaves differently on different systems (Windows/macOS) which seems weird. |
|
Can you not use a global.json, install workloads, and then delete the global.json? Without a global.json, am I understanding correctly that it's not that you use the 6.0.200 sdk but rather you use the workloads from 6.0.200? Could you use a rollback file to solve this? My change might fix this but it's really hard to tell as that switch was not meant for this scenario unfortunately. It was originally fairly limited in scope (hence why it's hidden). I pinged the mono folks on the linked items to see if they can investigate as it looks like a mono issue. |
Well, that's one of the workarounds. It's just regression from 6.0.300 and few extra steps in the CI pipelines.
The desktop MSBuild picks the 6.0.2xx SDK (if both 6.0.400 and 6.0.2xx are installed) along with the workloads for that band. Since the installation now installs the workloads for the latest band instead of the old - explicitly specified - one I end up with non-working scenario.
As far as I can tell, no. Don't rollback files still install the workloads for the latest SDK band? Even if they didn't then I would need to be explicit about the versions of each package. I prefer not to. I want to get the latest servicing for a given SDK band. |
|
Checking back on this, is there still a need to use one SDK to install workloads into a different SDK? That was never part of the design and not really was --sdk-version was for. Using each SDk to install for itself and using rollback files is the guidance. Are you unblocked by moving forward to a newer sdk/vs combo? |
Yes, there is, until #25651 is fixed. |
|
That issue explains why you need to install older workloads into an older SDK but not why you need --sdk-version. I'm still not clear why you can't use a global.json to pin to the older SDK, then install workloads at that time with a rollback file if you need a specific version, and build that way. I pinged Larry on the other issue as likely on the runtime side. |
The workload installation is done by the CI job at the beginning of the process. It is done independently of checking out the source code.
Most projects in the solution actually want the latest SDK and workloads since they target .NET 6. I need to install the workloads in both the current SDK and the old one to allow compilation of the legacy Xamarin projects. global.json doesn't help here because I would need more than one to accomplish this and that's quite clunky.
It's on SDK/MSBuild side, it was already moved between Xamarin, dotnet/runtime and dotnet/sdk repositories in the past. |
|
I appreciate the explanation. That helps me better understand why you need it as it particular to the ordering of your CI build. Note that we --sdk-version was not intended for this nor is your scenario intended to work at this time. As for the other bug, I wouldn't expect it to be sdk related. I would have thought it'd be something in the workload targets. That being said, it looks like you're using mono. I don't think we've tested or support workloads with mono. How old are the mono bits at this point? |
I originally reported our broken scenario in #25651. We use Mono MSBuild to compile projects that reference multi-target libraries. These referenced libraries often include something like
net6.0-macosin the TFM along withnetstandard2.1. SDK 6.0.300 band broke the builds as described in the linked issue. The workaround was to install also the 6.0.200 band which was picked up by the desktop Mono MSBuild and worked fine. This required installation of workloads throughdotnet workload install --sdk-version 6.0.203 macos. Since 6.0.400 SDK was published the workaround no longer works. The MSBuild complains about missing workloads even though it references the 6.0.203 SDK in the paths in log:The workload installation log:
I originally didn't want to open separate issue but it looks like other people started running into similar issues on Azure Devops when the new 400-band SDK was released (taken from Twitter in the dotnet community):
This is heads up that something likely got broken even though I cannot quite nail down what. The common thing seems to be that both of us use some sort of CI environment. In our case (GitHub Actions w/ self-hosted runners) the .NET installation is local in the $HOME/.dotnet directory, installed through actions/setup-dotnet. I will try to direct people to this issue to share more details.
The text was updated successfully, but these errors were encountered: