microsoft / vscode-dotnettools

This is a feedback repository to capture issues logged for the C# Dev Kit and related extensions from Visual Studio Code
Other
210 stars 7 forks source link

[BUG] C# dev kit should respect the `dotnet.dotnetPath` set by C# extension #792

Open ShreyasJejurkar opened 7 months ago

ShreyasJejurkar commented 7 months ago

Describe the Issue

If I set a custom path for dotnet SDK and runtime for C# extension using setting dotnet.dotnetPath like below.

    "dotnet.dotnetPath": "C:\\Users\\{username}\\AppData\\Local\\Microsoft\\dotnet"

I can see the C# extension uses that to load the base language service. image

but if I see C# dev kit (and it's test explorer) logs, it's still loading it's tooling from the SDK found on the path. image

which I think is incorrect, C# dev kit should respect the SDK chosen by base C# extension.

AbhitejJohn commented 7 months ago

@peterwald : Did we already address this?

peterwald commented 7 months ago

C# Dev Kit's Test Explorer does not use the dotnet.dotnetPath currently. We should probably update it to use the same setting here as the C# extension.

ShreyasJejurkar commented 7 months ago

1 thing of 100 things.

C# Dev kit components should not deviate from the options set by base C# extension. This single thing will avoid plethora of bugs and issues.

kepiz commented 7 months ago

Any way to fix this in the meantime?

peterwald commented 7 months ago

The extension has been updated to set the DOTNET_ROOT for child processes to the value of dotnet.dotnetPath when set. The change will ship in the next prerelease version.

ShreyasJejurkar commented 6 months ago

Is this even made to pre-release or not yet? I have the below version installed. image

When I check logs, I still see the C# dev kit loading the runtime from the path variable instead of the configured one in VSCode JSON settings.

image

peterwald commented 6 months ago

@ShreyasJejurkar Yes, that change should be in pre-release.

Note that the log message you are seeing there is a different code path than what I updated. I believe that log message is showing which instance of .NET is being used to run the language services.

After my change, child processes of the extension (i.e. your tests) should run with DOTNET_ROOT set in the environment to the value of dotnet.dotnetPath.

Can you describe what you are trying to accomplish here?

ShreyasJejurkar commented 6 months ago

I believe that log message is showing which instance of .NET is being used to run the language services

I don't think that is true, because when I see the base C# extension logs, I can see it's using the dotnetPath set by me in settings.json which is correct.

image

But whereas if you see the C# dev kit and its component, they are still loading their stuff from the dotnet found on the path, instead of using the ones that the user has configured using dotnet:dotnetPath.

image

image

So the issue, the C# dev kit and its component should not load their components from another dotnet sdk if the user has configured the dotnetpath in settings.

peterwald commented 6 months ago

@lifengl @arkalyanms @timheuer Do you have any thoughts on this? This is not a testing issue, it's more core to the dev environment.

nagilson commented 2 months ago

Awkwardly, there is another setting for the same thing from the .NET Install Tool extension / runtime extension. C#DK would need an update to respect this setting, and we'd probably want to decide which setting takes precedence.

Besides PM work this is a well understood issue. Just need to prioritize.

rmarinho commented 1 month ago

Hey, this seems to not be working as expected, and I see more bugs related with this experience.

The .NET MAUI team has need for this feature to work, because is the only way we could load our custom installation with bits that are not yet release and need some testing. This actually works fine with Visual Studio on windows and it even worked with Visual Studio Mac.

My understanding is that if we set the correct environment variables, c# dev kit would just load our provisioned dotnet and workloads instead of the global ones

Here' s the workflow..

========================================
VSCode
========================================
Setting environment variable: RestorePackagesPath = '/var/folders/4p/2__p2v8s73q7wgtbhbvchngc0000gn/T/Microsoft.Maui.Cache/NuGet/packages'
Setting environment variable: NUGET_PACKAGES = '/var/folders/4p/2__p2v8s73q7wgtbhbvchngc0000gn/T/Microsoft.Maui.Cache/NuGet/packages'
Setting environment variable: VSDebugger_ValidateDotnetDebugLibSignatures = '0'
Setting environment variable: DOTNET_INSTALL_DIR = '/Users/ruimarinho/dotnet/maui/bin/dotnet'
Setting environment variable: DOTNET_ROOT = '/Users/ruimarinho/dotnet/maui/bin/dotnet'
Setting environment variable: DOTNET_MSBUILD_SDK_RESOLVER_CLI_DIR = '/Users/ruimarinho/dotnet/maui/bin/dotnet'
Setting environment variable: DOTNET_MULTILEVEL_LOOKUP = '0'
Setting environment variable: MSBuildEnableWorkloadResolver = 'true'
Setting environment variable: PATH = '/Users/ruimarinho/dotnet/maui/bin/dotnet:/Users/ruimarinho/dotnet/maui/bin/dotnet:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/usr/local/share/dotnet:/Users/ruimarinho/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Users/ruimarinho/bin:/Users/ruimarinho/Library/Developer/Xamarin/android-sdk-macosx/cmdline-tools/latest/bin:~/.dotnet/tools:/Users/ruimarinho/Library/Developer/Xamarin/android-sdk-macosx/platform-tools:/Users/ruimarinho/Library/Developer/Xamarin/android-sdk-macosx/tools:/Users/ruimarinho/Library/Developer/Xamarin/android-sdk-macosx/tools/bin:/Users/ruimarinho/Library/Developer/Xamarin/android-sdk-macosx/tools/emulator:/Users/ruimarinho/Library/Python/3.9/bin'
/Users/ruimarinho/dotnet/maui/bin/dotnet:/Users/ruimarinho/dotnet/maui/bin/dotnet:/Users/ruimarinho/dotnet/maui/bin/dotnet:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/usr/local/share/dotnet:/Users/ruimarinho/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Users/ruimarinho/bin:/Users/ruimarinho/Library/Developer/Xamarin/android-sdk-macosx/cmdline-tools/latest/bin:~/.dotnet/tools:/Users/ruimarinho/Library/Developer/Xamarin/android-sdk-macosx/platform-tools:/Users/ruimarinho/Library/Developer/Xamarin/android-sdk-macosx/tools:/Users/ruimarinho/Library/Developer/Xamarin/android-sdk-macosx/tools/bin:/Users/ruimarinho/Library/Developer/Xamarin/android-sdk-macosx/tools/emulator:/Users/ruimarinho/Library/Python/3.9/bin
nagilson commented 1 month ago

@rmarinho Per internal discussion, we would like to get a repro of what you're facing and maybe a dump of the .NET Host to see which .NET is being picked up.