1

How does one programmatically determine the currently active dotnet version? I can run dnvm list, but cannot for the life of me get it to transfer output to a variable, file, string... nothing appears to work and I can't fathom why.

dnvm list > currentList.txt

results in the output still being displayed at the console and nothing redirected to file.

It doesn't appear to be writing to StdErr - 2>&1 doesn't change anything...

If anyone could even provide some insight into why this won't work, it would be much appreciated. Is there a Powershell way of querying this properly that I'm missing?

BenAlabaster
  • 39,070
  • 21
  • 110
  • 151
  • Just to clarify: You want to [retrieve the versions of `.Net` available](http://stackoverflow.com/a/3495491/2486496), or do you want to get the output of `dnvm list` piped properly, instead of displayed via console? – gravity Jul 07 '16 at 13:12
  • Well, I need to be able to programmatically determine if version the build is targeted for is installed and currently set active, and if not, make it so... automatically. So... how that happens is quite immaterial to me, just _that_ it happens. If there's a more appropriate way of doing this in Powershell, I'm happy to take that route. – BenAlabaster Jul 07 '16 at 13:39

2 Answers2

1

In your $env:UserProfile\.dnx\bin folder you will find a dnvm.ps1 script. Analyzing this, you can see what isn't obvious from the console help - it's just a command file that delegates to this ps1 script - any of the function arguments can be passed from the command line and the command will just pass them right through to PowerShell. So you can do something like this:

#This is the version we're looking to run against
$required = @{
    Version = "1.0.0-rc1-update2";
    Architecture = "x64";
    Runtime = "clr";
    OperatingSystem = "win"
}

#Check to see if the version we need is installed...
$installed = (dnvm list -PassThru | ? { 
    $_.Version -eq $required.Version -and 
    $_.Architecture -eq $required.Architecture -and 
    $_.Runtime -eq $required.Runtime -and 
    $_.OperatingSystem -eq $required.OperatingSystem
})

if ($installed -eq $null) {
    # The version we require isn't installed... 
    #   ...installing it will set it as active
    dnvm install -VersionNuPkgOrAlias $required.Version `
                 -Architecture $required.Architecture `
                 -Runtime $required.Runtime `
                 -OS $required.OperatingSystem
}
elseif (!$installed.Active) {
    # The version we require is already installed...
    #  ...just set it active
    dnvm use -VersionOrAlias $required.Version `
             -Architecture $required.Architecture `
             -Runtime $required.Runtime `
             -OS $required.OperatingSystem
}
BenAlabaster
  • 39,070
  • 21
  • 110
  • 151
-1

dnx and dnvm are gone and dotnet uses a different model. There is no 'active' runtime anymore. Now the runtime the application was compiled against will be used to run the application.

Pawel
  • 31,342
  • 4
  • 73
  • 104
  • This doesn't answer my question, for various reasons, we're stuck for the moment with dnx, and hence dnvm because the drivers for other third party software we need haven't yet been updated for dotnet core. – BenAlabaster Jul 07 '16 at 14:43
  • If you could use third party libraries with dnx you should be able to use them in .NET Core. If the problem is that they targeted dnxcore50 you just need `imports`. If they target dnx451 you can use target full .NET Framework in .NET Core projects as well. If this is something different I would be interested to know. – Pawel Jul 07 '16 at 16:34