Create release from TFS fails with client tools 6.8.0

TFS builds fail on “Create Octopus Release” step (version 3.*) after octopus client tools are upgraded to 6.8.0. Same applies for “Push Packages to Octopus” step

The command:
D:\Builds\Agent_work_tool\Octo\6.8.0\x64\Octo.cmd create-release “–project=MiljoeOverblik” “–releaseNumber=1.0.19170.5” “–channel=Default” “–server=” “–apiKey=***” --enableServiceMessages "–releaseNotesFile=D:\Builds\Agent_work\2524\s\"tfs.create.release.6.8.0.txt (19.7 KB)

gives the following error: (note the date format on the build server is Danish)

Unable to process response from server: String was not recognized as a valid DateTime… Response content: [
2019-06-19T07:59:04.3788952Z {
2019-06-19T07:59:04.3789058Z “Id”: “packages-Brf.Deploy.1.0.19164.3”,
2019-06-19T07:59:04.3789195Z “NuGetPackageId”: “Brf.Deploy”,
2019-06-19T07:59:04.3789307Z “PackageId”: “Brf.Deploy”,
2019-06-19T07:59:04.3789824Z “NuGetFeedId”: “feeds-builtin”,
2019-06-19T07:59:04.3789944Z “FeedId”: “feeds-builtin”,
2019-06-19T07:59:04.3790059Z “Title”: null,
2019-06-19T07:59:04.3790162Z “Summary”: null,
2019-06-19T07:59:04.3790277Z “Version”: “1.0.19164.3”,
2019-06-19T07:59:04.3790380Z “Description”: “Brf.Deploy”,
2019-06-19T07:59:04.3790491Z “Published”: “13. juni 2019 13:32”,
2019-06-19T07:59:04.3790615Z “ReleaseNotes”: null,
2019-06-19T07:59:04.3790718Z “FileExtension”: “.nupkg”,
2019-06-19T07:59:04.3790816Z “Links”: {
2019-06-19T07:59:04.3790945Z “Self”: “/api/packages/packages-Brf.Deploy.1.0.19164.3”,
2019-06-19T07:59:04.3791077Z “AllVersions”: “/api/packages?nuGetPackageId=Brf.Deploy”,
2019-06-19T07:59:04.3791197Z “Feed”: “/api/feeds/feeds-builtin”,
2019-06-19T07:59:04.3791338Z “Raw”: “/api/packages/packages-Brf.Deploy.1.0.19164.3/raw”
2019-06-19T07:59:04.3791445Z }
2019-06-19T07:59:04.3791526Z },
2019-06-19T07:59:04.3791629Z {
2019-06-19T07:59:04.3791732Z “Id”: “packages-Brf.Deploy.1.0.19164.2”,
2019-06-19T07:59:04.3791843Z “NuGetPackageId”: “Brf.Deploy”,
2019-06-19T07:59:04.3791975Z “PackageId”: “Brf.Deploy”,
2019-06-19T07:59:04.3792078Z “NuGetFeedId”: “feeds-builtin”,
2019-06-19T07:59:04.3792202Z “FeedId”: “feeds-builtin”,
2019-06-19T07:59:04.3792300Z “Title”: null,
2019-06-19T07:59:04.3792395Z “Summary”: null,
2019-06-19T07:59:04.3792506Z “Version”: “1.0.19164.2”,
2019-06-19T07:59:04.3792608Z “Description”: “Brf.Deploy”,
2019-06-19T07:59:04.3792745Z “Published”: “13. juni 2019 10:10”
2019-06-19T07:59:04.3799644Z Error from Octopus Server (HTTP 200 OK)
2019-06-19T07:59:04.3799781Z Exit code: -7

Full log from TFS is attached.

I have just encountered exactly the same issue (UK date format on build server though).

Had the same issue here in Ireland. Found this link which provided a workaround that solved it for me:

Any task we had at version 3 was failing, but version 2 works. Our Octopus server version is out of date, so that could potentially be the long term solution.


1 Like

Getting similar issues with the task “Push package(s) to octopus” in Azure Devops.

Doesnt matter what request it is, the task seem to be unable to read the server response with the error message: “Unable to process response from server: String was not recognized as a valid DateTime…”

Unfortunately we can not use the V2.* workaround, cause we do not even have the V2.* option in the task dropdowns in Azure Devops.

Same issue.

We downgraded to Octopus Deploy Command Line Tool, version 6.7.0 from 6.8.0 and it works fine now.

In Azure Devops you can, as a temporary workaround, before doing any octopus tasks, add the task “Octopus tools installer”, and enter 6.7.0 as version number.

I would probably be smart to remove that if a fix for this is released, something i will likely forget…

I am using Erik’s workaround for now, which seems to do the trick

Hi everyone,

We have fixed this issue (, and have released 6.8.1 of the Octo.exe, which resolves the issue. The next time the ADO/TFS plugin runs a task, it should download the new version (if you are not manually specifying a previous version).

We sincerely apologize for the inconvenience caused by this situation.

Hi Justin,

Is there a problem with 6.8.1? The newer version did fix my issue and my releases were running correctly. However, suddenly Azure DevOps is using 6.8.0 again and my releases are failing.

We are still receiving the error. What do you mean by ‘it should download’? When? Is there something we need to adjust on our side?

UPDATE The TFS build task is working now.

Glad it’s working - turns out Cloudflare was holding on to a stale cache on one of our “latest version” URLs on some geographical regions/servers. We just fixed this up so you should get 6.8.1 on the next task if you hadn’t previously.

Apologies again for the inconvenience of all of this.

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