-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove custom logic of fetching dotnet dir #26851
Conversation
src/Cli/dotnet/CommonOptions.cs
Outdated
return dotnetRootPath; | ||
// Get the dotnet directory, while ignoring custom msbuild resolvers | ||
return Microsoft.DotNet.NativeWrapper.EnvironmentProvider.GetDotnetExeDirectory(key => | ||
key.Equals("DOTNET_MSBUILD_SDK_RESOLVER_CLI_DIR", StringComparison.InvariantCultureIgnoreCase) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% clear on why you want to ignore this environment variable here? Is it basically not supposed to be used when getting dotnet for the common options but should still be used in the EnvironmentProvider (hence the override)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great question @marcpopMSFT! I had the exactly same one and I addressed it to you: #26837 (comment)
Can you please help identify proper owner in CLI and help find the answer?
de30783
to
7cb5cc6
Compare
a903560
to
4e20e35
Compare
3c22057
to
7a1ffd7
Compare
2b6b664
to
b99e5bb
Compare
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Fixes #26837
Proposal of removing custom hardcoded logic of fetching dotnet dir location.
EnvironmentProvider.GetDotnetExeDirectory()
now first checks the current process (thus handling the case of xcopy dotnet install) and environemnt after that.CommonOptions.GetCurrentRuntimeId()
now do not have it's custom logic of locating the dotnet folder. It calls theEnvironmentProvider.GetDotnetExeDirectory()
, but it doesn't intentionally recognize custom MSBuild resolver (defined viaDOTNET_MSBUILD_SDK_RESOLVER_CLI_DIR
env var) - so that it's in line with previous logicSince this is not code I own/maintain, I'd appreciate any insight if there are opposing ideas. Specifically:
EnvironmentProvider.GetDotnetExeDirectory()
?tagging @sfoslund here as the original author
CommonOptions.GetCurrentRuntimeId()
fine ignoring the custom MSBuild resolver (as it was before)?tagging @marcpopMSFT as the supposed owner of the code.