If I have two frameworks installed with same version, but different runtimes, one of them having an alias assigned, then doing dnvm use [alias] -p will result in selecting correct framework for current session, but may select wrong one for "permanent". Specifying the -r option explicitly fixes the behavior.
Example:
[fsoikin@CentOS ~]$ dnvm list
Active Version Runtime Architecture OperatingSystem Alias
------ ------- ------- ------------ --------------- -----
1.0.0-beta7 coreclr x64 linux
1.0.0-beta8 coreclr x64 linux
* 1.0.0-rc1-update1 coreclr x64 linux rc1, default
1.0.0-rc1-update1 mono linux/osx
1.0.0-rc2-16317 coreclr x64 linux rc2
[fsoikin@CentOS ~]$ dnvm use rc1 -p
Adding /home/fsoikin/.dnx/runtimes/dnx-coreclr-linux-x64.1.0.0-rc1-update1/bin to process PATH
Updating alias 'default' to 'dnx-mono.1.0.0-rc1-update1'
[fsoikin@CentOS ~]$ dnvm use rc1 -r coreclr -p
Adding /home/fsoikin/.dnx/runtimes/dnx-coreclr-linux-x64.1.0.0-rc1-update1/bin to process PATH
Updating alias 'default' to 'dnx-coreclr-linux-x64.1.0.0-rc1-update1'
[fsoikin@CentOS ~]$
Thanks for reporting this issue. For RC2, we're planning to retire dnvm, dnx and dnu in favor of dotnet CLI. Moving this to backlog until the transition.
If I have two frameworks installed with same version, but different runtimes, one of them having an alias assigned, then doing
dnvm use [alias] -p
will result in selecting correct framework for current session, but may select wrong one for "permanent". Specifying the-r
option explicitly fixes the behavior.Example: