Thank you for the report - I have confirmed this particular page is validating the privilege at the system level instead of the feed level, we'll have it fixed in the next maintenance release.

This was fixed in one of the versions we released this year, if you upgrade to the newest version it should work correctly. Make sure to read the Upgrade Notes for each minor version since 2.2 (i.e. 3.0 thru 3.3), and back up your ProGet database before upgrading (the installer should offer this option) as there have been significant changes to feed storage and indexing. You'll also want to read the KB article about Migrating Legacy Feeds.

We can add a configurable throttle to the timer that triggers a package rescan. In the meantime, you can always trigger an immediate index rebuild by either setting the RebuildPackageIndex setting (under Admin->All Settings) to True, or by restarting the ProGet service.

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.

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.

In this case, it sounds like the service account has some sort of enumeration problem with groups. This is not uncommon. As a test, i would suggestto run the ProGet webapp (either in IIS or the hosted web service) with your domain account. And of course, if you do find out specifically what caused this from the groups/permissions side of things, an update would most certainly be appreciated :)

Not possible currently, but something we could definitely add - I'll put an issue in for this.

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>

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

I can't seem to repro this - if I specify an API key for the feed that requires one, I get this error message: Failed to process request. 'There was an error processing the request: You are not authorized to add a package to this feed. By default, ProGet is not configured to allow unauthenticated users to publish packages to a feed. You will need to either authenticate (by using "name:pass" as your API Key) or give the Anonymous User the Feeds_AddPackage privilege.'. If I then use Admin:Admin or allow anonymous users to publish, then it works as expected. Did you change the Admin user's password by chance?

ProGet runs just fine in Hyper-V; you may want to try a reboot... that will often fix it. The problem is usually the WMI service acting up

If you wrap the first package query in parentheses it should work: http://proget-server/nuget/{feedName}/Packages?$filter=(Id eq 'ProjectName.Deploy') and startswith(Version,'1.0')&$top=1&$orderby=Created desc

Hi Riko Was this issue resolved for you I am facing similar issues with ldap in my company.

Unfortunately, NuGet does not distinguish between symbol and normal packages when uploading; all that's sent from the client is the package name, id, and bytes. Thus, there's no way to have ProGet automatically merge. In this case, you'll need to combine both packages in one, then upload it. Alternatively, you can create a symbols-only feed and upload to that.

Sorry about that, I got a little confused with BuildMaster's configuration... there is no appSettings.config file for ProGet :-/ ProGet's website port is determined by arguments passed to the service. If you stop the ProGet service, run ProGet.Service.exe as administrator, and choose Uninstall, the service will be uninstalled. You can run it again and choose "Install" to add it back, then it will ask for the URL to reserve, and you can enter something like http://*:1000/ to reserve all hostnames on port 1000. Make sure to choose an identity that has access to the SQL Server database. If you chose Network Service as the account to use when you first installed, just leave that as the default option for the user account when prompted. If the service takes a while to start up (i.e. longer than 5 seconds), it probably means the user account assigned to run the service does not have access to the DB (it could take a minute or more to time out). Just reinstall the service in the same manner to host with a different user.

Which older version of nuget works correctly?

That's correct in that it's too early to read the file, which is why it results in the sharing violation (the file is opened for write by w3wp.exe without FileShare.Read). The new file in the directory triggers the FileWatcher (which doesn't find the file because it's not completely written yet). However, the NotifyChangeDirectory operation in the feed directory will trigger the FileWatcher again after the file is completely written and closed in which case it would get picked up by the indexer, and that would make the package appear in the feed. Is there a way to run the monitor again to cross-reference the times that the error appears in the ProGet error log with a violation within the Process Monitor log? I am thinking that these particular sharing violations are not related to the errors you're seeing.

That sounds great, thanks a lot!

Oh I see what you mean - I thought you meant that you were able to upload packages using the NuGet client... I was able to reproduce in that way. We'll have a fix for this in maintenance release v3.0.4 (logged as issue PG-210). Apologies for the confusion.

Yes, although you may get some file read errors if someone happens to be downloading the exact package that's being backed-up or copied. Many back-up processes/tools will do things like shadow copy and limited read handles to prevent this from happening.