I have installed the “Create Octopus Release” task from https://marketplace.visualstudio.com/items?itemName=octopusdeploy.octopus-deploy-build-release-tasks on our on-premise TFS 2015 Update 2 server.
I have two different build machines - one runs Windows 2008R2 and has VS 2013 installed. When I build a VS solution on this machine and trigger the “Create Octopus Release” step it functions without any issues. The other build machine runs Windows 2012R2 and does not have any version of VS installed. When I build on this machine (just executing some PowerShell scripts to create various .nuget packages) and it attempts to trigger the “Create Octopus Release” step I get the following errors:
##[error]The term ‘Get-ServiceEndpoint’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
##[error]You cannot call a method on a null-valued expression.
##[error]The term ‘Get-ServiceEndPoint’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
##[error]The remote server returned an error: (401) Unauthorized.
##[error]Cannot bind argument to parameter ‘InputObject’ because it is null.
##[error]You cannot call a method on a null-valued expression.
##[error]The remote server returned an error: (401) Unauthorized.
##[error]Cannot bind argument to parameter ‘InputObject’ because it is null.
##[error]The term ‘Invoke-Tool’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Both build definitions have the step configured the same way, and both machines have the VSO agent running under the same AD user - one call to the “Create Octopus Release” step works and one does not.
What am I missing?
Hi Richard,
We’re very sorry you’re experiencing this issue.
It seems Microsoft have renamed the VSTS PowerShell Cmdlets in the latest versions of the VSO agent. We only became aware of this yesterday.
We are working on a fix for this (you can track this GitHub issue). The solution for us is to bundle all the PowerShell modules we require with our task, avoiding this problem in the future.
In the meantime, I would suggest configuring your release process to only run on the working agent. Ideally I would suggest installing an older (and working) version of the VSO agent, but I can’t find anywhere to obtain previous versions of the Windows agent.
Again, we sincerely apologize. We will resolve this as soon as possible.
Please let us know if there is anything else we can do to assist.
Regards,
Michael
That’s one thing I can’t do - the different machines have different capabilities and I can’t get one to do it all.
I’ve checked the version of the agent on each machine, and they are both 14.95.25122.0 - I don’t understand how one works and the other doesn’t if it’s down to a change to the VSO agent itself. I’m starting to wonder if the different operating systems are playing a part - or at least the version of PowerShell that is installed.
The machine that works is Windows 2008R2:
CLRVersion 4.0.30319.34209
BuildVersion 6.3.9600.16406
and the machine that doesn’t work is Windows 2012R2:
CLRVersion 4.0.30319.42000
BuildVersion 6.3.9600.17400
The script “Octopus-CreateRelease.ps1” contains this snippet of code:
Import-Module “Microsoft.TeamFoundation.DistributedTask.Task.Common”
When I attempt to execute this script manually on the machine that works to track it’s behavior it fails at this point with this error:
Import-Module : The specified module ‘Microsoft.TeamFoundation.DistributedTask.Task.Common’ was not loaded because no valid module file was found in any module directory.
I assume the “$env:PSModulePath” is modified prior to the execution of this script to include the path to this module to allow the script to function - perhaps the difference in PowerShell versions between my two machines causes this to fail?
Where did you find your agent version (14.95.25122.0)?
I thought the agent version was usually something like 1.82.0.
It’s the FileVersion property of “VsoAgentService.exe”
No ideas on what else I can try?
I apologize in advance if these solutions don’t work, but two ideas that I think may be worth trying:
If that doesn’t work…
- Try installing Visual Studio on the failing agent.
Please let me know if you have any success with this? I hope to have some good news regarding an updated Octopus extension very soon.
Sorry for the delay - I was doing a bit of further investigation… and found the solution. I had a new vanilla Windows 10 machine created for me to test on, and had no issues with building on that machine. After comparing this machine against the Windows 2012R2 machine it turned out to be the version of PowerShell itself, which was fixed by installing Windows Management Framework 5.0 onto the Windows 2012R2 machine. Once that was done, we could build successfully with no further changes. Why we can build on a Windows 2008R2 machine that doesn’t have Windows Management Framework 5.0 installed is beyond me though.
That’s interesting…
I’m glad to hear you solved it.
Happy Deployments!
Installing Windows Updates on a Windows Server 2012 R2 box resolved the issue for me.