Hi Bret, For question #1 - We have just published this documentation for TeamCity: https://inedo.com/support/documentation/buildmaster/builds/external-systems/teamcity This may give you a little more guidance on that subject. For question #2- all of our tutorials are here: https://inedo.com/support/tutorials but this one might be what you are looking for https://inedo.com/support/tutorials/buildmaster/continuous-integration/manage-pipelines-git Thanks, Jason

Hi Bret, A tutorial for TeamCity is here: https://inedo.com/support/tutorials/buildmaster/teamcity/choosing-specific-artifact-from-teamcity Future note, the TeamCity tutorial may be moved to https://github.com/inedo/inedox-teamcity/wiki as part of a docs re-organization. As for controlling Apache, this is done through the httpd command, which can be executed with an Exec operation in your deployment plans, e.g.: # Deploy to Apache { Exec httpd -k stop; # deploy artifacts... Exec httpd -k start; }

We don't have any guides on this integration specifically, but the usual situation is that TC can't authenticate. The easiest thing to do is to allow anonymous publishing to the feed, but not overwriting. Otherwise, you can try to get the authentication to properly work, which typically involves sending username/password or configurating an API key properly.

Hello Rob, I've released version 1.0.1 of the TeamCity extension, which should fix this (or at least give a more sensible error message). It should be available in /administration/extensions.

Unfortunately we're not able to diagnose this with the information you provided. That error really doesn't make sense in the place it's happening. Can you please submit a ticket with: Configuration Variables defined at various levels (System, etc) Plan as OtterScript Pipeline as JSON Full Execution log, including the full stack trace you sent

I don't think you're doing anything wrong, but based on this, and your previous error... it sounds like you've got some server/network oddities. That could be any one of a THOUSAND things, but it's definitely not ProGet nor the NuGet clients. So, I'd suggest to put some wireshark or fiddler monitoring in between to see exactly what's happening, where they are coming from, and what the actual responses are.

Thanks Alana. I upgraded to Proget v3.5.6 and updated the timeout period for the nuget feed source to 30s. Now I am no longer getting that issue but I am getting a different one. I logged it as a separate question: http://inedo.com/support/questions/2969

Reworking that page was already on our list of things to do for the next version, so this won't be an issue after that :) Thanks for your help!

Yet one more solution (after 6+ months). After trying all the possible solutions mentioned above - if you are still seeing the error: Response status code does not indicate success: 405 (Method Not Allowed). then most likely you need to disable your WebDav IIS plugin. You may either remove the IIS feature from the machine or if you need to keep the feature you may disable it only for this website. You may do this by editing the Web.config file (by default located here: C:\Program Files\ProGet\WebApp) and add two entries as shown below: <system.webServer> <modules> <remove name="WebDAVModule" /> </modules> <handlers> <remove name="WebDAV" /> </handlers> </system.webServer>" Note: the Modules and Handlers section should already exist, you only need to add the line <remove name="xxx"> for each section. I think Proget Dev team should integrate this in the Web.config by default to prevent future issues.. Thanks HS

I believe TeamCity requires that the APIkey is passed in, regardless of if the feed requires it or not. You can just use name:pass as the api key in this case.

Same issue here, tried with Local Users, LDAP and Windows AD, with and without API. Did anyone managed to solve this? Thanks!

This is not a very common scenario, so I would suggest altering your workflow to not always update the packages if they don't change. Alternatively you'll need to add some custom steps such as deleting the package before pushing it, or using a custom package store.

Thanks, Tod, that was the conclusion I came to as well. I created it, issue #3.

This problem is a pretty big deal - it means that existing TeamCity build artifacts can't be "pulled" into ProGet. The only way to make it work is for new build output, pushing nuget output to ProGet. That's suboptimal.