Regarding the first error – that sort of thing should only happen if the connector returns invalid data. What is the URL of the bower connector? For the registration, it looks like it’s just an HTTP 401. See this article for info about Bower & authentication in ProGet: http://inedo.com/support/kb/1095/introducing-bower-support-for-proget

Ah, I see; please note that we do not support v1 feeds (they were already obsolete when we build ProGet in 2012) and we have no intention to. Suggest you push packages from TeamCity to ProGet instead.

I can't reproduce this problem; the query always works for me. Could you send a fiddler trace of the failed request to support at inedo.com?

Looks like there was an additional issue being caused by the feed metadata being slightly off. We've published another fix (v3.3.4).

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

This is a known bug with NuGet Package Explorer. It appends "/api/v2/package" to the URL when it shouldn't. Here is the related issue: http://npe.codeplex.com/workitem/144 The correct behavior is described in the first scenario here.

Hi Tod, Restarting the service fixed the issue. I broke a few CI builds, but oh well! Thanks for the help.

Running from console asked me for some input, so entered 1 to Run the service, then entered the feed url that I wanted to start. It then found all of the packages and updated the database. However, upon pushing more packages, I found that those packages weren't updated. Once this happened, I remembered that I had to explicitly create a SQL user for the ProGet database (our server team doesn't allow local server accounts to authenticate to SQL but our domain accounts can). Once I edited the ProGet.Service.exe.config file with the correct credentials, it worked as expected. Thanks so much for the help and the very quick responses! Dave

We will be adding a few fixes to help with retrying after indexing issues in the next maintenance release, as well as some more logging to figure out what is going wrong in these cases. Long term, we will also be redoing a lot of the indexing logic to eliminate these types of problems (but that probably will happen in a minor/major release.)

At some point, the NuGet client started requesting every package version instead of just the latest for updates. The only way to fix this on our end is to add paging/result limiting for feed output. We could hack in a configurable result limit pretty easily which should fix this for you in a maintenance release.

Hi Tod Sorry for that, these are the correct images: ProGet browser https://www.dropbox.com/s/lp00uc995s3h5rl/2014-07-10 15_28_09-GamePlay 2.0.23.png Nuget Package Explorer https://www.dropbox.com/s/ev7bteduhh7hkb3/2014-07-10 17_44_31-NuGet Package Explorer_GamePlay.2.0.23.png The request from Nuget Explorer fails and I assume the same thing happens with the Nuget Package Manager in Visual Studio: Request: GET http://srvsedevtfs01:81/nuget/default/FindPackagesById()?$orderby=Published%20desc&$select=Id,Version,Authors,DownloadCount,VersionDownloadCount,PackageHash,PackageSize,Published&id='XXXXXX.XXXXXX.XXXXXX.GamePlay' HTTP/1.1 DataServiceVersion: 2.0;NetFx MaxDataServiceVersion: 2.0;NetFx User-Agent: NuGet Package Explorer/3.8.0.0 (Microsoft Windows NT 6.1.7601 Service Pack 1) Accept: application/atom+xml,application/xml Accept-Charset: UTF-8 Host: srvsedevtfs01:81 Accept-Encoding: gzip, deflate Response: HTTP/1.1 404 Not Found Cache-Control: private Content-Length: 6505 Content-Type: text/html; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 X-AspNet-Version: 4.0.30319 X-UA-Compatible: IE=edge Date: Fri, 11 Jul 2014 14:30:39 GMT <h1> Request handler not found (404) </h1> <div class="subH1"> An unexpected error has occured while processing your request. </div> <h2>Error Details:</h2> <div style="overflow: auto; height: 100px; border: 1px dotted #A00; padding: 10px; color: #A00;"> /nuget/default/FindPackagesById()?$orderby=Published%20desc&amp;$select=Id,Version,Authors,DownloadCount,VersionDownloadCount,PackageHash,PackageSize,Published&amp;id=&#39;XXXXXX.XXXXXX.XXXXXX.GamePlay&#39; does not map to any handlers. The URL may have been entered incorrectly or linked to from an old reference. </div> <h2>Why am I seeing this page?</h2> <p> You were taken to this page because ProGet encountered an error without a specific or known resolution. </p> <h2>What else can I do about this?</h2> <p> Hopefully the error message above is helpful in determining what went wrong. </p>

Thanks for the report - we are able to repro and will fix it in the next maintenance release.

I just noticed you actually have already released 2.2.5 I confirm that it does resolve our issue. Great support, thank you!

Sounds good, by early next week we'll have some very specific documents that include exact deployment plans showing how we personally handle some cases with dependencies (specifically, how the BuildMaster installer deployment is automated, even though it depends on 4 separately-built BuildMaster extensions and BuildMaster itself). In the meantime, the feature as we've categorized it is Dependency Management: http://inedo.com/buildmaster/features/dependency-management

We've seen this happening with some connected feeds, and unfortunabely there is no workaround (aside from not using the connected feeds). This has to do with the translation of UTC dates between External Feeds (NuGet.org) and ProGet. We will have a new version (2.0.1) out today to resolve this.

Ah, thanks; it would appear I wasn't on the latest version of NuGet... where this seems to be an issue. This is related to the aforementioned issue and should get resolved by PG 2.0.

This is a known issue (PG-61) that seems to have started with NuGet 2.2 (maybe 2.1?); our notes read as "if a package has a pre-release version and a stable version, only the pre-release version is shown." It's scheduled to be fixed in the next maintenance release.

In ProGet 1.x releases (current), package metadata is not stored in the database -- it's just in-memory, and is recreated when the server restarts. In ProGet 2.x (coming soon), we will be storing package metadata in the database and will thus have an ability to retain this information. We'll also be integrating some more in-depth package usage analytics using some bits from Gibraltar Loupe ( http://www.gibraltarsoftware.com/loupe/Default.aspx ) -- though that likely won't make the 2.0 cut.

Ah, definitely a bug -- will be fixed in next release, (1.1.4 or later)

Great - working well! Thanks