Azure-pipelines-tasks: .NET Core Tool Installer should allow defining a base path for finding a global.json

[NetTecture]

Current version requires me to define the installed SDK version hardcoded.

We use a GIT standard flow where different branches have different purposes (master is release, develop is where we develop actively).

I need the same build flow to select the sdk version based on a global.json in the hierarchy of folders, nothardcode it. so that when I build master, it uses the sdk version installed in that branch' global.json, and when I build develop, it does use another one.

Right now I need to separate build definitiony based on the branch being build. NOT nice.

Beset would be to define a root path from which the standard global.json search rules will apply.

[amaljg]

@NetTecture Apologies for the delayed response. Somehow, this issue got missed out of our radar.

Thanks for your feedback. Currently, the task is not designed to work with global.json. I'm adding @pulkitaggarwl to consider this for future.

For now, to workaround this limitation, you can use a build/release variable (say SdkVersion) as the value for 'Version' parameter and have another PowerShell task (prior to the .NET Core Tool Installer task) to determine this SDK version based on your global.json and set the SdkVersion variable with the appropriate value.

Hope this helps!

[twurm]

@amaljg, @pulkitaggarwl I agree that it would make life a lot easier if the task looked to see if a global.json file was found in the root folder of the solution.

[NetTecture]

@amaljg @puagarwa Even worse. Not sure anyone spent more than 10 minutes thinking about it. We run a build cascade through various branches. Now I have to separate which build gets done on each branc hbased on changes in the version in the global.json. If this tool would acutally work according to the dotnet specs, I could just update develop and it would SLOWLY move down towards release, as I merge the new json over. Now - mess like hell.

That is not a workaround, amaljg - that is hose ** stinking all the way into development. It makes automated builds something that regularly breaks AND then requires hot fixes on the production branch.

[vtbassmatt]

@NetTecture I'm sorry that this issue is frustrating. Please strive to be friendly, patient, welcoming, and respectful in your communications with us. We'll continue to return the favor.

@amaljg's comments are a perfectly acceptable workaround. For another: I see that global.json is read from the current working directory or any parents, and all tasks accept an optional working directory of your choice. Can you use that? (I'm not an expert in how dotnet resolves global.json files, so I really don't know.) Finally, we accept pull requests in this repository, and we appreciate the contributions of passionate individuals.

[twurm]

I’ll take a wake at the suggested work around this week sometime. Once I get things working I’ll post the PowerShell here. @vtbassmatt I did look at the code just to make the change, the shell script stuff isn’t my thing. So for now this seems like the best solution.

[vtbassmatt]

Thanks @twurm! If you find a better workaround than the ones proposed here, I'm sure it will be appreciated.

No PRs or contributions are expected, but I wanted to use the opportunity to remind folks that they're accepted :grin:

[twurm]

@NetTecture, @vtbassmatt here is a quick and dirty solution eventually we will clean it up further but for now it works and solves the issue of SDK Upgrades.

1. Create a new Variable in your Pipeline called: SdkVersion
2. Create a new PowerShell task in you Pipeline before "Use .Net Core Version xyz" task
3. Set the PowerShell task type to InLine and set the body to:

$PathToGlobalJson = Join-Path -Path $Env:BUILD_SOURCESDIRECTORY -ChildPath "global.json"
Write-Host "global.json location: $PathToGlobalJson"
$GlobalJson = Get-Content -Raw -Path  $PathToGlobalJson | ConvertFrom-Json
$Version= $GlobalJson.sdk.version

Write-Host "SDKVersion: $Version"

Write-Host ("##vso[task.setvariable variable=SdkVersion;]$Version")

1. Edit your "Use .Net Core Version xyz" task and set the version to:

$(SdkVersion)

Again its a quick and dirty solution but seems to do the trick.