Then I get the error:
Task definition with id 179fac12-2402-486e-80cf-5a6a8571f7c0 was installed via the tfx-cli or REST API and cannot be replaced using contribution octopusdeploy.octopus-deploy-build-release-tasks.octopus-pack. Please delete the task using the tfx-cli or REST API before replacing it with a contribution.
I have deleted the old task but I still get this error. How do I solve this problem?
Thanks for getting in touch. This is a problem we’ve only seen once before, and it’s a bit tricky to resolve unfortunately.
Can you confirm that you ran the following command to delete the task, after authenticating with your local TFS server with the tfx-cli? tfx build tasks delete -task-id 179fac12-2402-486e-80cf-5a6a8571f7c0
If so, the next step is to gather a bit of info on the task itself and where it’s being stored.
Can you run these queries on both the config and collection databases for your TFS instance? SELECT * FROM Task.tbl_TaskDefinition where TaskId = '179FAC12-2402-486E-80CF-5A6A8571F7C0'
SELECT * FROM Task.tbl_TaskDefinition where TaskId = '4E131B60-5532-4362-95B6-7C67D9841B4F'
And let us know which of the databases returns results if any?
The suspicion last time this occurred was that the tfx-cli was pointing to the incorrect DB while deleting the task, so we want to make sure we know where the task lives.
Are you able to use Fiddler to do a trace while you both get the task details (tfx build tasks list), and when you try to delete it (tfx build tasks delete)?
Sorry for late reply.
The solution to this was to go back to TFS 2015 and remove the Octodeploy task in TFS 2015, and then do the upgrade again to TFS 2017 and install the Octodeploy task again in TFS 2017.
Now it is working.
Thanks for taking the time to get back to us and let us know about the fix. Sorry to hear it involved that much work. One can only dream that one day MS will make TFS a much easier to troubleshoot tool
Hi Damian and other Octopus Support people. Bit late to the game for this one but I too have found this exact same issue, Was just doing an upgrade from 2.0.44 to 2.0.78 in Prod and though to check our Staging environment but found I had a really old version in staging that I must have installed using TFX-CLI when the DB was TFS 2015, now its 2017.2 but still had a remnant of the old Octopus 0.3.0 (don’t know if that is your version, or a version I created)
id : 4e131b60-5532-4362-95b6-7c67d9841b4f
name : OctopusCreateRelease
friendly name : Create Octopus Release
visibility : Build,Release
description : Create a Release in Octopus Deploy
version : 0.3.0
I did a SELECT * FROM Task.tbl_TaskDefinition where TaskId = ‘4E131B60-5532-4362-95B6-7C67D9841B4F’ from the Config DB, I deleted it, maybe I shouldn’t have but there still seems to be more to remove, do you know what else I need to remove in the DB to clear it out so I can install the latest vsix package?
NOTE - The latest TFX-CLI doesn’t delete the Build Task, says it was successful but when you run a list again, it still there.
So that we can help you troubleshoot, would you please be able to get some more information for us?
The VSIX package includes 5 commands, you may have to delete all of them before upgrading:
Each of the tasks also has a FilePath that points to a zip file, you may need to ensure that this is removed after issuing the delete command. I would suggest just moving the files to be on the safe side.
After deleting each of the tasks out of the database, and confirming through the task list command, please post back any upgrade error messages you continue to receive.
Fixed - The version we have on our TFS staging environment predated the vsix package, Its the 0.3.0 version that only has 4E131B60-5532-4362-95B6-7C67D9841B4F Create Octopus Release in the config db, I deleted it from the config database but I still couldn’t install the new vsix package. Turns out all I needed to do was to restart the AppTier, the website must have been caching parts of the config db, Not to sure how it works under the hood but a restart fixed it.