Skip to content
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

Merged
merged 2 commits into from
Sep 9, 2022

Conversation

JanKrivanek
Copy link
Member

@JanKrivanek JanKrivanek commented Jul 28, 2022

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 the EnvironmentProvider.GetDotnetExeDirectory(), but it doesn't intentionally recognize custom MSBuild resolver (defined via DOTNET_MSBUILD_SDK_RESOLVER_CLI_DIR env var) - so that it's in line with previous logic
  • Utils are adjusted to allow injection of env under tests and tests are adjusted to inject mocked env.

Since this is not code I own/maintain, I'd appreciate any insight if there are opposing ideas. Specifically:

  • Is there any issue with switching order of checks in EnvironmentProvider.GetDotnetExeDirectory()?
    tagging @sfoslund here as the original author
  • Is the CommonOptions.GetCurrentRuntimeId() fine ignoring the custom MSBuild resolver (as it was before)?
    tagging @marcpopMSFT as the supposed owner of the code.

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)
Copy link
Member

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)?

Copy link
Member Author

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?

@JanKrivanek JanKrivanek force-pushed the GetDotnetDir branch 2 times, most recently from a903560 to 4e20e35 Compare August 18, 2022 07:22
@JanKrivanek JanKrivanek marked this pull request as ready for review August 19, 2022 12:11
@JanKrivanek JanKrivanek requested a review from a team as a code owner August 19, 2022 12:11
@JanKrivanek
Copy link
Member Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@JanKrivanek JanKrivanek merged commit 517aa20 into dotnet:main Sep 9, 2022
@JanKrivanek JanKrivanek deleted the GetDotnetDir branch September 9, 2022 12:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

questionable file name assumptions baked into SDK
2 participants