Experienced this issue when carrying out a live deployment. There’s various StackOverflow topics on the subject but it appears to be an issue with Azure deployment. Re-deploy and all should be fine.
A current annoying quirk it seems. Adding a task through the marketplace and installing to the correct organisation. Going into the pipeline and then attempting to add this task shows the task as “installed” but little else – I’m unable to add the task.
Had a number of TeamCity projects connecting to the Git repo using my user account. Was thinking I should really request for service accounts to do the connection. This becomes a pain when I change my user password as I have to remember to go in to TeamCity and Octopus Deploy to update the passwords on anything using my user account. Really bad practice!
After doing a bit of digging I stumbled across “Deploy Keys” whereby you can gen ssh keys to configure Git and TeamCity to play nicely with each other so that deploy keys are then used to establish a read only connection from Team City to Git to pull down the repository.
Steps as follows:
- Generate ssh keys ssh-keygen -t rsa -C “firstname.lastname@example.org”
- Go to Git project settings. Click on Deploy Key – Add the public key – I had to paste the full contents of public key here although I believe some versions will allow upload of file.
- Go to TeamCity. Click on the Project. “Edit Project Settings”…….”SSH Keys”…..”Upload SSH Key” – Upload the private SSH key.
- Now go into the Team City project settings and “Edit Configuration Settings” ….. “Version Control Settings” …..”Edit”…..Under “Authentication Settings” change the “Authentication Method” to “Uploaded Key” and select the “Uploaded Key” to the key you uploaded in step 3.
- Depending on how you had the Version Control Settings configured previously you may need to now switch to the SSH version of the “Fetch URL” in the configuration settings.
All done. No more dodgy personal accounts used for TeamCity and Git interaction.
Me and the DBA were rolling out quite a sizeable deployment into production. We were about half way through our deployment checklist (also known as the runbook). It was going well, too well in fact. We’d had no issues and everything was incredibly smooth.
Of course there shouldn’t really be any issues, as by this point, deployments (hopefully automated) to test environments and pre-prod/UAT will have happened along with the runbook documented and approved with all relevant team members and Change Manager(s).
So, I’d deployed out some of the apps as part of the product rollout. I moved on to some SSIS components that are doing some fairly sizeable file processing and number crunching along with many transforms. Myself and another Senior Developer had written a class library that was referenced by the SSIS components. The class library needed registering in the GAC. Not an issue, I’d copied the gacutil command and the dlls required for registering into a folder as part of the deployment pack. On the production server I cracked up the cmd prompt with Admin rights and issued the following:-
gacutil /i CompanyName.Library.dll
And nothing, well we had a response from gacutil which gave us the gactuil .net version and the command prompt. No error, great move on, but I noticed I’d not seen an “… installed” message. Confused I checked the Gac and sure enough the library was missing.
Hmmmm, this is strange. Had I inadvertently build the DLL targeting the wrong .Net Framework (that’s pretty amateur!)?Back to my DEV VM and I checked the framework. No it’s fine so what gives??
The Gacutil MSDN page doesn’t offer anything else apart from what I already know. After a quick stackoverflow search and google nothing was really giving me any clues. The release schedule window was ticking away and I was running out of ideas.
Luckily, a colleague had done something similar just mere weeks ago. Having chatted to him he mentioned something about the 1033 folder and a further dependency DLL residing in said folder. Once you have the other dll in the folder and gacutil issuing the command again gives you the install message and all is good with the world!
Of course once you know about the 1033 folder googling brings up lots of results on this issue