Properly setup DOTNET_ROOT env

[uvlad7]

No description provided.

[hensou]

Closing as it currenly only sets DOTNET_ROOT in the context of dotnet command and it does not work for running tools.

[uvlad7]

@hensou can you please provide more context? I use mise instead of asdf and this patch worked for me. I used asdf-elixir as an example.

[hensou]

Sure @uvlad7. First, I've been using nix so I'm might be lagging behind in asdf, and I'm also not familiar with mise, so let me know if I'm missing something.

My test case was done by:

1. installing the plugin with its version using asdf plugin add dotnet https://github.com/uvlad7/asdf-dotnet
2. Then asdf install dotnet latest.
3. Then asdf global dotnet 9.0.102.
4. Finally, dotnet --version shows that everything works as expected.

However, let's say you want to install a tool like fsautocomplete with dotnet install -g fsautocomplete (if it's the first time you're installing, you'll also need to add the .tools directory to your PATH). After installation, you should be able to run fsautocomplete, but it won't work because it won't find the DOTNET_ROOT variable, since it's only visible when you run exec-env when running dotnet commands.

This also happens with mise, unless I explicitly create a shell session with mise activate.

I think it would be nice to have your PR, but at the same time I think it could lead to unexpected problems, as it won't be clear why all the other commands that have the dotnet in it and require the DOTNET_ROOT env work, but the tools don't.

Do you have any idea if it is possible to achieve something like mise activate in asdf?

I've tried with asdf shell dotnet 9.0.102 but that did not work.

[hensou]

There is this issue for more context #54

[uvlad7]

I'm unable to look at this problem right now, it'll take a week or more. I'll take a look, but can't promise anything, because I'm not an expert, I just copied this from elixir plugin. But it indeed worked for globally installed tools in my environment. I use mise activate and it just works. Not sure about asdf

[uvlad7]

@hensou So I finally took a look and tried to test your example, and yes, I was able to reproduce the same behavior, but only when outside of a directory with dotnet activated, and it makes sense as I don't have it enabled globally (but it's possible in mise, don't see that option in asdf). So you need to run your tool from a directory with dotnet activated. I'd be better to customize installation directory to make it present only if dotnet is active, though, or (I guess) it can cause cryptic errors if another dotnet version is activated. Now it is installed in ~/.dotnet/tools, which I have added to PATH in my .profile.

AFAIK there is no common approach to (global) install path configuration, same happens with npm (which uses #!/usr/bin/env node to run exec installed in global ~/.npm-packages/bin, so wrong tool version gives you an error) or pip (which just hardcodes current python in the shebang, and seems to install packages into $ASDF_INSTALL_DIR/bin, but my ~/.local/bin is full of these installs too, and not only from pre-mise times). So my solution is to keep global tools the same version as system ones (to avoid previously installed tools that use #!/usr/bin/env tool break) and do global installs only with these global versions. And plugins cannot change tools approach in terms do they hardcode themselves into shebang or use env, but a separate bin makes sense in both cases, even if hardcoded path will work, it's not supposed to, if the tool isn't activated, and env version won't work if package isn't installed, as these scripts are just wrappers. But compiled languages are different, global install makes sense (still both go and rust seem to install into $ASDF_INSTALL_DIR/bin)

Still a mess, will compare all used plugins later.

[hensou]

I think I'll accept this MR and add a note on the Readme about the need for manually setting the DOTNET_ROOT variable in case you have tools from multiple dotnet versions.

I'll just add that to this PR and will merge it.

Thanks a lot!