[BUG] dotnet restore does not use CLI from dotnet.dotnetPath

[sandyarmstrong]

Describe the Issue

Errors like the following occur during restore:

/usr/local/share/dotnet/sdk/7.0.203/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.ImportWorkloads.targets(38,5): error NETSDK1147: To build this project, the following workloads must be installed: macos

Note that it is using the global dotnet SDK location instead of the one specified in dotnet.dotnetPath.

It seems like the implementation of dotnetCommand does not take this setting into account.

Steps To Reproduce

1. Have a solution with projects that depend on .NET workloads (for example, macos or maui).
2. Use a locally-provisioned .NET SDK for builds, where those workloads are properly installed.
3. Specify the path for that .NET SDK in dotnet.dotnetPath in workspace settings.
4. Open solution in VS Code.

Expected Behavior

NuGet restore should work without issue.

Environment Information

• C# Dev Kit extension v0.1.83
• C# extension v2.0.206

[kartheekp-ms]

@arkalyanms - I have removed area-restore label to this issue because @marcpopMSFT added area-sdk label. Given that this issue appears to be related to .NET SDK, I have removed my assignment for this issue.

[marcpopMSFT]

That setting is not for controlling the SDK or the customer's dotnet environment but rather just for the local install of the runtime used in the devkit extension per my understanding:
Specified the path to a dotnet installation to use instead of the default system one. This only influences the dotnet installation to use for hosting the language server itself. Example: "/home/username/mycustomdotnetdirectory".

So the behavior you're seeing seems pretty expected to me. Not sure why you wanted to control this through the IDE settings as we've never had the ability to control dotnet outside of the path/global.json (and global.json doesn't control where the SDK is, only environment variables).

CC @lifengl who probably knows where that setting is actually used.

[sandyarmstrong]

Not sure why you wanted to control this through the IDE settings as we've never had the ability to control dotnet outside of the path/global.json (and global.json doesn't control where the SDK is, only environment variables).

But we should have this ability. See also dotnet/sdk#8254.

[nagilson]

@marcpopMSFT @baronfel This is part of the 'GA' milestone so we should resolve it before then, I don't know if we have any actionable items we can do from this by GA, and whether this should be a fix in the SDK, VS Code Runtime Ext, or CDK/C#. If you have more context on this issue, may you please advise? Thank you ;)

[nagilson]

We talked about it more; it looks like CDK has a dotnetCommand which you are referring to and that is not part of the SDK or Runtime Extension, you would have to change that code to make it use the dotnet on the setting you mentioned as dotnet.dotnetPath. As for the change in the SDK, that is not accomplishable by GA and is a separate issue that should be tracked in the SDK itself like you mentioned. Any follow up can go there, it's a great point but I'm not sure when it will be done.

[sandyarmstrong]

@nagilson so where is the best place to file C# Dev Kit bugs?

[nagilson]

Here is good -- for the dotnetCommand, @kartheekp-ms may you please check and see if this CDK restore command could adhere to using the dotnet.dotnetPath?

[nagilson]

If that is not even a viable option, please let us know @marcpopMSFT

[marcpopMSFT]

To clarify, the original ask was for a settings that would control the location of the SDK used by C#DK. The existing setting is specific to the version of the runtime being used by the extension and does not apply to the SDK calls (builds, restores, tests, etc). I don't think we want individual teams in DK implementing ways of finding and honoring a flag.

We don't have a way of specifying an alternative way of doing this outside of the PATH environment variable and per the linked issue, there is disagreement on what an alternative solution would look like. I think this is a reasonable ask but probably something that should be fixed by global.json rather than DK.

[nagilson]

Ok, I agree this is more of an SDK issue. Sorry. @kartheekp-ms my earlier comment was not a good idea, Like, you could change the behavior of just the restore command but I think then it would be disparate from all of the other commands. So, you would likely have to change the behavior for all of the commands, which is really just something that should be done in the SDK.

This is the correct place for CDK feedback but this change should really be tracked in the SDK.

[sandyarmstrong]

The existing setting is specific to the version of the runtime being used by the extension and does not apply to the SDK calls (builds, restores, tests, etc).

Gotcha. Hopefully this is well-documented in the settings to avoid future confusion.

[nagilson]

I will close this since the SDK issue should be tracking this