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

Implement the "dotNetCliPaths" option to support custom .NET SDK locations #4738

Merged
merged 9 commits into from
Aug 23, 2022

Conversation

jkoritzinsky
Copy link
Member

@SamB
Copy link

SamB commented Oct 31, 2021

... don't you need to register the option in package.json ?

@jkoritzinsky
Copy link
Member Author

@SamB I did not realize I needed to do that. Done!

@JoeRobich
Copy link
Member

@jkoritzinsky The c# extension also performs a check for dotnet to be on the PATH. Now that we are adding the ability to specify additional paths, can you update the getDotnetInfo function to return results when dotnet isn't on the path but instead specified by the new setting.

@gregg-miskelly
Copy link
Contributor

gregg-miskelly commented Nov 3, 2021

The debugger also needs to find dotnet. So this directory probably needs to be added to PATH through DebugAdapterExecutable.options.env in createDebugAdapterDescriptor.

There are also build tasks that need to use dotnet, but I am not sure if there is a good way to add that to the PATH that VS Code uses, or if users would need to manually edit tasks.json.

…t` CLI for the target processes. Update the definition of the dotnetPath option to explain how it differs. (dotnetPath will only apply for hosting OmniSharp. dotNetCliPaths applies for any dotnet processes that are launched for debugging, test discovery, etc)
@jkoritzinsky
Copy link
Member Author

@gregg-miskelly @JoeRobich I've finally had a chance to get back to this PR. I've updated it to master and implemented both of your requests. Can you take another look when you have a chance?

…(the one Omnisharp will run on), not the target dotnet cli.
jkoritzinsky added a commit to jkoritzinsky/dotnet-runtime-test-assistant that referenced this pull request Aug 4, 2022
…on so OmniSharp will run tests against the correct runtime.

Refactor OutputConfiguration into a separate file from userPrompts.

Fixes #8 as best as possible.

This still depends on either the PATH and DOTNET_ROOT being set to the correct folder (like how the -vs flag on the dotnet/runtime build.cmd script has), a global SDK being installed with a new enough version, or dotnet/vscode-csharp#4738 being implemented.
Copy link
Member

@JoeRobich JoeRobich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jkoritzinsky Thanks for sticking with this PR!

test/unitTests/Fakes/FakeOptions.ts Outdated Show resolved Hide resolved
src/features/commands.ts Outdated Show resolved Hide resolved
src/utils/getDotnetInfo.ts Show resolved Hide resolved
@jkoritzinsky
Copy link
Member Author

@JoeRobich @filipw can one of you merge this PR for me? Or is there something else I need to do before we get this merged in?

@JoeRobich
Copy link
Member

@jkoritzinsky Sorry for the delay. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants