csmith wrote:...your delay may be down to the speed of the connection between the Deployment Manager server and Nuget server
I do see that after the first "30 second" wait, the package list loads instantly. So there is some sort of caching going on. But it still makes no sense that it would take so long to load a list of 20 items from my local C drive. I'm hoping the deployment team can shed some light on this.lee5i3 wrote:I occasionally get the same problem, I just try again and it works
justin.caldicott wrote:Just to add my 2ct to this.
I saw very similar build results in TeamCity. I was calling DeploymentManager.exe to create the release and deploy. The process was returning error code 400, after two minutes of trying to find the latest version number for packages. Lee, what do your TeamCity logs look like? Similar?
I fixed it by manually removing older packages from the built-in feed. I'd been creating a lot of them from the automatic commit trigger. @Michael, you mentioned having 20 packages in the feed. Are there more than that if you include all of the different versions of the packages?
Deployment Manager's built-in feed is using NuGet.Server, which doesn't have any indexing. If you need a faster feed, then you might look at using either ProGet, MyGet or the NuGet Gallery codebase.
Personally I really like using the built-in feed, as I like to keep deployment and dependency packages separate. (I'm using NuGet packages for internal dependencies too.) Also, the Deployment Manager server feels like the right place to keep these packages, as it's the only consumer. So my vote would be for adding indexing to the Deployment Manager built-in feed, so that it "just works", even with larger numbers of packages.
Users browsing this forum: No registered users and 1 guest