Add detection if 'dotnet' is not on the path on RHEL

[gregg-miskelly]

Steps to reproduce

Machine: Red Hat Enterprise Linux 7.2

1. Follow instructions on https://github.com/Microsoft/MIEngine/wiki/Logging#using-shipping-bits to install the CLI
2. Install VS Code
3. Install the C# extension

Expected behavior

Debugger should restore, projects should build, OmniSharp should be able to run dotnet restore, etc.

Actual behavior

None of these work because 'dotnet' isn't on PATH

Work around

Launch VS Code from the .NET environment with:

scl-enable rh-dotnetcore10 code

[omajid]

Hi! Since you make calls to dotnet restore (what about dotnet run?) I wouldn't recommend workaround 2 or 3. Both of them add the dotnet binary to path, but miss out on other things.

For example, currently on RHEL 7, /path/to/dotnet run will use the system version of libcurl.so, which is linked against nss compared to the rh-dotnetcore10-libcurl version of libcurl.so which is linked against openssl. The scl command overrides LD_LIBRARY_PATH to make this happen.

In the future, using scl may also set up additional NuGet repositories for dotnet to use, so that may cause an additional difference between invoking dotnet directly compard to using scl.

Yet another workaround is to do something like scl list-collections | grep dotnet and then try and use scl enable <name from previous command> -- dotnet instead of the dotnet command from VS Code. This way, you can do things like scl enable rh-dotnetcore10 -- dotnet restore -v which works just like dotnet restore -v should. And the user doesn't have to launch VS Code in an scl session.

[gregg-miskelly]

Thanks @omajid

I removed those work arounds from the original list (they are listed here in case someone wants to understand what your comment referred to in the future).

Old work arounds (not recommended)
2: setpath.sh
Add a setpath.sh script to /etc/profile.d directory with the contents: export PATH=$PATH:<path-to-directory-containing-dotnet>. Make it executable (i.e. chmod 777). Log out and log back in and dotnet is now always on the path.

3: Create a symlink to dotnet from a directory on PATH

[Swimburger]

I'm running into the same issues, but with VS Code Remote Development extension.
As a workaround I could create a symlink from dotnet to ~/bin/dotnet and it starts working fine.

But how can we actually use the suggested solution scl-enable rh-dotnetcore10 code with VS Code Remote Development extesion?

Edit: for anyone in the same scenario, new issue #3471.

[gregg-miskelly]

@Swimburger your issue is similar, but NOT the same. The command you are quoting is specific to the RedHat distribution of the .NET Core SDK, and is therefore NOT at all what you want. I am not sure why the VS Code extension host you are using isn't seeing the PATH changes that the .NET SDK installer would make. But if you want to open another issue we can see if we can help. Note that this isn't a problem with this extension, but we will see if there is something we can advise on.