We have reproduced this, and determined that it has to do with the way nuget.org handles casing. If all lowercase (Id='jquery.cookie') is used, then results are returned. This is because we currently handle these types of queries by just translating them to use a filter instead (Id eq 'jQuery.Cookie'), for compatibility with older servers, and it seems that the 'eq' operator is always case-sensitive on nuget.org. We may not need to be doing this translation at all anymore, since it's been a while since that new syntax has been introduced, but for now we will make a change to wrap this type of query in a tolower() odata function, which we have confirmed fixes the issue with this package. We'll include this fix in the next maintenance release.

Thanks for the report, I logged this as an issue to further investigate... PG-492

Cached packages are used for downloads only and not metadata. If you need the metadata, you will have to pull the package to ProGet instead of just cache it. Then it will be available even if the connector is unreachable. Note: as of ProGet 3.3 and newer, this is no longer true. Cached packages are now used for metadata queries as well as downloads.

In my case, I was generating the "real" packages in Release build configuration but generating the symbol packages in Debug build configuration. Once I realized the symbol server wouldn't respond correctly when the build configuration differs between the packages, I published the symbol packages in Release build configuration so the packages matched and everything started working correctly. Hope this helps someone else in this same situation!

In this case, it may be best to switch to IIS as the web server to host ProGet. The integrated server is meant more for simplicity and getting started more quickly, and isn't as robust when dealing with these types of network issues. The instructions to do so are here: http://inedo.com/support/kb/1013/hosting-buildmaster-or-proget-through-iis-instead-of-the-integrated-web-server

The feed directory can only contain package files, and remember that a ".symbols.nupkg" is not a valid package file. The ".symbol" file is just a bizarre hack the NuGet team put together to allow you to push half of your package to nuget.org and the other half to symbolsource.org. The nuget.exe client strips the ".symbols" from the name (so the server has no idea what type of file it's receiving). For ProGet, you just have to have everything in a single package... or create a separate feed that the symbol half of your pckage can go to. Basically, you just need to write a script to combine these two files into one. They're just zip files so it should be pretty easy.

Thank you for the report. It turns out if the package title is different from the ID, only the title is searched for the list command. We have fixed this on the ProGet end to search both ID and title regardless of difference and are planning on releasing v3.2 today which will include the fix. You could also hack that chocolatey script to use nuget list id:arenaframework-client which should work with the version of ProGet you already have.

That's unfortunate, but understood. Thank you for your timely response. However, I certainly wouldn't classify the workaround as easy with an actively released package such as EasyNetQ. Am I right in assuming the workaround would require manually monitoring for new versions on NuGet and pulling the new packages to ProGet whenever a new version is released? If so, that is quite an administrative overhead. I'm sure there are other packages on NuGet which have crossed the 100 releases boundary (or are nearing it), so this is probably not an isolated case.

Ok, figured it out. The Nuget.exe version I was using was 2.0, I updated to latest (2.8.1) and now I can get versions other than 3.3.0 for NServicebus.Interfaces. Thanks for your help!

Thanks Tod - it seems to have been a problem with our proxy settings but I've got it sorted now.

You would just need to create a second feed, and then copy all of the packages on disk from one to the other.

Make sure your feed is configured to cache packages (Admin > Manage Feeds > Edit Properties) and you'll see them in C:\ProgramData\ProGet\Packages\Default\_cache once they've been downloaded/restored:

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 possible using the SDK if you implement a custom package store (to allow ProGet to index packages stored in s3 and to allow it to push packages there), and an OData adapter to alter the package download URL sent back to clients. Our Creating a Custom Package Store tutorial is out of date in terms of the implementation (we are updating much of our tutorials/documentation this week), but there should be enough there to get you started. In short, you'd need to implement PackageStore and ODataAdapterBase. If you need a reference implementation of either, let us know and we can send it to you.

hi there - you'll want to use the API for this; http://inedo.com/support/documentation/proget/reference/api-methods Note that you can use the SDK if you'd like, and call the API methods via "StoredProcs.METHODNAME.Execute()"

Thanks for the detailed investigation! We have logged this as PG-250 and a fix will be included in the next release (v3.1.7). Provided there's no issues with testing, you can expect this release later today.

Sure does! See ProGet Silent Installation for more info.

TeamCity uses NuGet API v1... which was already deprecated when we build ProGet. So, in this case, you will need to push packages to PRoGet from TeamCity if you want to integrate.

We're thinking about it; if NPM proves to be successful and of interest, we would like to branch out to other repositories.

Yes, removing the privileges for the anonymous user will force authentication in the feed. You can also set an API key for the feed similar to NuGet.org feeds. For more info, see: http://inedo.com/support/documentation/proget/feeds/api-keys