Get-ToolPath cmdlet is no longer recognised after agent update to 199 on hosted?

This issue is a follow-up of a short twitter discussion here Here is the context of the issue:

Initially, we tried to use few tasks for cloud artefact deployment, and they didn’t work well. We hadn’t got much success with AZCopy task too, but after some PowerShell fiddling, we got AzCopy tool working in a regular "Azure PowerShell " script.

To discover AzCopy location I was using snippet from one of other tasks I found in the repo: $azcopy = Get-ToolPath -Name "AzCopy/AzCopy.exe"

This script was working fine on Monday 09 May, but started to fail next day, with no obvious reason - we haven’t touched our build scripts for a long time. The screenshot in the tweet shows the error message. The only difference between failed and successful builds I found after studying logs, is that agent version on the hosted build changed from 1.98.1 to 1.99

I tried to get working the code above using Azure Powershell task and just a regular Powershell task with same results:

The ‘Get-ToolPath’ command was found in the module ‘Microsoft.TeamFoundation.DistributedTask.Task.Internal’, but the module could not be loaded. For more information, run ‘Import-Module Microsoft.TeamFoundation.DistributedTask.Task.Internal’.

I’m not sure if this problem is global, it seems that it may affect only our assigned Hosted Agent instance, but we can’t really do anything with it - we can’t control Hosted Agent instance. Also, it’s a bit strange that previously working CI pipeline started to break without any external changes.

PS: I managed to work around the problem using standard AzCopy task ( this time it started to work out of the box). I also saw that AzCopy Task itself is using similar code to detect AzCopy binary location, and it’s working fine now on the same agent. Which makes me think that the problem in the Azure Powershell and Powershell tasks or their contexts\modules, not in the breakage of a particular Agent instance.

[centur]

We have to jump back to ad-hoc scripts when something is broken or not yet exists. So unless you want to build a completely closed system - then it’s reasonable to prevent users from finding some ways around the existing problems.

Otherwise - ad-hoc Powershell script is exactly The Solution - the users last resort to do something they want/need but it wasn’t yet designed in the system, or will never be in. And having a friendly basic scripting environment is a good starting point to do this.

Having paths hard-coded usually means - to rely on the default installations, paths and SDKs. It’s obviously a way to go sometimes (not a good practice though), but it lacks any discover-ability - user has to know that this tool belongs to specific SDK, of the specific version and that SDK by default installed in particular location and a given agent… Well, when there is no nicer way to go around - I’d rather check in my own binaries in the repo and will have a full control there, instead of rely on some hard-coded paths and non-guaranteed promises. Some others may just change a build system and never get back to such problems again

[ericsciple]

For tools where the installer doesn’t add it to the PATH, I think your best bet would be to look for it in well-known locations (e.g. in this case Azure SDK installation directory).

I’ll go ahead an close this issue, since Get-ToolPath (previously delivered by the module Microsoft.TeamFoundation.DistributedTask.Task.Internal) was internal detail of the task implementation, that happened to work before from your ad hoc Azure PowerShell script. The cmdlet was intended only for internal usage by the in-the-box tasks, and was only used to find 4 different tools. The in-the-box tasks away from this module.

I see your point that it would be nice for ad hoc script to have a way to resolve well known tools, but a PowerShell cmdlet cannot be solution. It won’t work for any other type of ad hoc script (batch, exe, shell script, etc).