Open ShreyasJejurkar opened 7 months ago
@peterwald : Did we already address this?
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.
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.
Any way to fix this in the meantime?
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.
Is this even made to pre-release or not yet? I have the below version installed.
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.
@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?
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.
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
.
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.
@lifengl @arkalyanms @timheuer Do you have any thoughts on this? This is not a testing issue, it's more core to the dev environment.
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.
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..
/Users/ruimarinho/dotnet/maui/bin/dotnet
========================================
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
@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.
Describe the Issue
If I set a custom path for dotnet SDK and runtime for C# extension using setting
dotnet.dotnetPath
like below.I can see the C# extension uses that to load the base language service.
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.
which I think is incorrect, C# dev kit should respect the SDK chosen by base C# extension.