Octopus Deploy Integration error 3.0.162

I receive the following error when trying to use version 3.0.162 of the Octopus Deploy Integration client with VSTS.

No agent found in pool Applications which satisfies the specified demands:
Agent.Version -gtVersion 2.115.0

Our current private agent version is 2.136.1.

If I revert back to the previous 2.0.* version of the integration, everything works fine.

Hi Scott, thanks for reaching out.

Version 3 of the VSTS plugin has been rewritten and requires DotNet Core. DotNetCore was not a required by version 2 of the plugin, so there is a good chance that this error was generated because there are no agents with the DotNetCore capability.

You can confirm this by looking at the capabilities of the agents. The screenshot below shows an example of the capabilities for an agent.

The solution would be to either stay on version 2, which does not require DotNetCore, or add the capability to your agents.

Matt C

We do have the latest .NET Core installed on our build agents. Does it require a specific version?

Here is a list of our agent capabilities:

System capabilities
Capability name Capability value
Agent.ComputerName BUILD02
Agent.HomeDirectory E:\Build021
Agent.Name BUILD021
Agent.OS Windows_NT
Agent.OSVersion 10.0.14393
Agent.Version 2.136.1
APPDATA C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming
ChocolateyInstall C:\ProgramData\chocolatey
Cmd C:\Windows\system32\cmd.exe
CommonProgramFiles C:\Program Files\Common Files
CommonProgramFiles(x86) C:\Program Files (x86)\Common Files
CommonProgramW6432 C:\Program Files\Common Files
ComSpec C:\Windows\system32\cmd.exe
DotNetFramework C:\Windows\Microsoft.NET\Framework64\v4.0.30319
DotNetFramework_2.0 C:\Windows\Microsoft.NET\Framework\v2.0.50727
DotNetFramework_2.0_x64 C:\Windows\Microsoft.NET\Framework64\v2.0.50727
DotNetFramework_3.0 C:\Windows\Microsoft.NET\Framework\v3.0
DotNetFramework_3.0_x64 C:\Windows\Microsoft.NET\Framework64\v3.0
DotNetFramework_3.5 C:\Windows\Microsoft.NET\Framework\v3.5
DotNetFramework_3.5_x64 C:\Windows\Microsoft.NET\Framework64\v3.5
DotNetFramework_4.7.0 C:\Windows\Microsoft.NET\Framework\v4.0.30319
DotNetFramework_4.7.0_x64 C:\Windows\Microsoft.NET\Framework64\v4.0.30319
FSHARPINSTALLDIR C:\Program Files (x86)\Microsoft SDKs\F#\10.1\Framework\v4.0\
InteractiveSession FALSE
java C:\Program Files\Java\jre1.8.0_171
java_8 C:\Program Files (x86)\Java\jre1.8.0_171
java_8_x64 C:\Program Files\Java\jre1.8.0_171
JAVA_HOME C:\Program Files\Java\jdk1.8.0_181
jdk C:\Program Files\Java\jdk1.8.0_181
jdk_8 C:\Program Files (x86)\Java\jdk1.8.0_172
jdk_8_x64 C:\Program Files\Java\jdk1.8.0_181
LOCALAPPDATA C:\Windows\ServiceProfiles\NetworkService\AppData\Local
MSBuild C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\
MSBuild_15.0 C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\
MSBuild_15.0_x64 C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\amd64\
MSBuild_2.0 C:\Windows\Microsoft.NET\Framework\v2.0.50727\
MSBuild_2.0_x64 C:\Windows\Microsoft.NET\Framework64\v2.0.50727\
MSBuild_3.5 C:\Windows\Microsoft.NET\Framework\v3.5\
MSBuild_3.5_x64 C:\Windows\Microsoft.NET\Framework64\v3.5\
MSBuild_4.0 C:\Windows\Microsoft.NET\Framework\v4.0.30319\
MSBuild_4.0_x64 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\
MSBuild_x64 C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\amd64\
MSBuildSDKsPath C:\Program Files\dotnet\sdk\2.1.300\Sdks
node.js C:\Program Files\nodejs\node.exe
npm C:\Program Files\nodejs\npm.cmd
OS Windows_NT
Path C:\Python27;C:\Python27\Scripts;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\ProgramData\chocolatey\bin;C:\Program Files\dotnet;C:\Program Files\Java\jdk1.8.0_172\bin;C:\opscode\chef\bin;C:\Program Files\Java\jdk1.8.0_181\bin;C:\Program Files\nodejs;C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\WindowsApps;C:\Windows\ServiceProfiles\NetworkService.dotnet\tools
PowerShell 5.1.14393.2339
PROCESSOR_IDENTIFIER Intel64 Family 6 Model 45 Stepping 2, GenuineIntel
ProgramData C:\ProgramData
ProgramFiles C:\Program Files
ProgramFiles(x86) C:\Program Files (x86)
ProgramW6432 C:\Program Files
PSModulePath %ProgramFiles%\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules
PUBLIC C:\Users\Public
SystemDrive C:
SystemRoot C:\Windows
TEMP C:\Windows\SERVIC~2\NETWOR~1\AppData\Local\Temp
TMP C:\Windows\SERVIC~2\NETWOR~1\AppData\Local\Temp
USERPROFILE C:\Windows\ServiceProfiles\NetworkService
VisualStudio C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\
VisualStudio_15.0 C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\
VisualStudio_IDE C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\
VisualStudio_IDE_15.0 C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\
VS140COMNTOOLS C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\
VSTest C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\TestWindow
VSTest_15.0 C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\TestWindow
windir C:\Windows
WindowsKit C:\Program Files (x86)\Windows Kits\8.1\
WindowsKit_8.1 C:\Program Files (x86)\Windows Kits\8.1\
WindowsSdk C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A
WindowsSdk_7.1 C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A
Xamarin.Android 8.3.3

I added the .NET Tools installer to install the latest SDK and it seems to be working, but it’s already installed on the build agent, so I’m not sure what the difference is.

Hi Scott,

Do you mean that you added this step to your build process?


If so, the .NET Core Tools installer satisfies the DotNetCore demand of the new Octopus plugins, which you can see from this screenshot of the DotNetCoreInstaller task.json file (https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/DotNetCoreInstallerV0/task.json). This in turn allows the Octopus task to complete.

Matt C

I did, but I shouldn’t have to since it’s already installed on the build server.

Hi Scott,

The .NET Core Tools installer is convenient, but not required if you have .NET Core already installed. You can manually add the DotNetCore capability to agents, and point it to the locally installed version of .NET Core.

The screenshot below shows an example of an agent with the DotNetCore capability defined.

Matt C

I had a similar issue, but only partly fixed by the adding the DotNetCore capability as described.

After the recent auto-update of the TFS/Octopus integration, by users complained that every release they got a message about missing DotNetCore as mentioned by the original poster. If they selected ‘Ignore’, then the release went through. This was with the version set at 2.*.

I installed dotnet core on my build server hosting my build agents, and added the DotNetCore user capability. This made the warnings go away.

However, if I change by release steps to use 3.* instead of 2.x, any Octopus steps fail with a timeout error:

2018-08-13T02:06:44.0227346Z ##[section]Starting: Package Mainline.PACK.OC.DMS
2018-08-13T02:06:44.0467570Z ==============================================================================
2018-08-13T02:06:44.0467570Z Task : Package Application
2018-08-13T02:06:44.0467570Z Description : Package your application into a NuPkg or Zip file.
2018-08-13T02:06:44.0467570Z Version : 3.0.165
2018-08-13T02:06:44.0467570Z Author : Octopus Deploy
2018-08-13T02:06:44.0476579Z Help : Version: 3.0.165. More Information
2018-08-13T02:06:44.0476579Z ==============================================================================
2018-08-13T02:07:08.3035242Z ##[error]Error: connect ETIMEDOUT
2018-08-13T02:07:08.3045214Z ##[error]Failed to execute octo pack command. connect ETIMEDOUT
2018-08-13T02:07:08.3275208Z ##[section]Finishing: Package Mainline.PACK.OC.DMS

If I switch back to 2.* again, the release to Octopus goes through.

Given dotnetcore is installed on the agent, why does this fail?

Hi Greg, thanks for reaching out.

The VSTS plugin is being updated to remove the DotNetCore requirement. This means it will no longer be necessary to have this requirement configured on the agents; it is enough to have .NET Core installed.

The error Failed to execute octo pack command means that the Octo cli was not located on the agents. The CLI will be automatically downloaded with the updated version of the TFS/VSTS plugin, or you can use the instructions at https://octopus.com/docs/api-and-integration/tfs-vsts/using-octopus-extension/install-octo-capability to manually install and configure the cli.

Matt C

Thanks Matt.

Can you give me a timescale on when the updated VSTS plugin will be available?

Hi Greg,

Version 3.0.166 has the DotNetCore demand removed, and that is available now, so you can update at any time.

Matt C

Hi again.

I’ve upgraded, but still get the same problem with Octopack. The error log message says it is timing out accessing this IP:
error: connect ETIMEDOUT

That’s not an IP I recognise, and I am pretty sure not one on our network. I can’t ping it, and NSLOOKUP does not recognise it either. Is there something in the TFS Octopus adapter trying to dial out?
Any thoughts?


Hi Greg,

That IP address is most likely the plugin attempting to download the Octo cli.

The new version of the plugin does not have the CLI bundled with it (as version 2 used to), and so either requires the CLI to be configured manually, or automatically downloaded.

To prevent the plugin from downloading the Octo cli you can use the instructions https://octopus.com/docs/api-and-integration/tfs-vsts/using-octopus-extension/install-octo-capability to manually install and configure the cli, which means the plugin will not attempt to download it.

Matt C

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.