Thats fixed it - Perfect thanks!

Strange. If you open the Tools->Options->Debugging dialog in Visual Studio, is the "Require source files to exactly match the original version" item checked? If it is not checked, that may cause it to use an old source file in the debugger. As far as I know, the PDB age is part of the symbol file's unique identifier - when Visual Studio asks for symbols, it makes a request to a URL with the PDB GUID and age. I think age normally gets incremented when a project is rebuilt in Visual Studio, though I don't know the rules about this for sure. Since you get the correct symbols/source if you clear out the symbol directory, I'm guessing Visual Studio just isn't making a request to ProGet because it thinks it already has the correct files. The best thing to do in this case is to run Fiddler and capture a trace of both behaviors and see what's different. You can send us a copy of these to support at inedo.com if you want some help troubleshooting.

Do you by chance have a space (or other reserved character) in the feed name? If so, make sure it is URL encoded when you access it, e.g.: http://domain.com:81/nuget/Feed Name With Spaces

I just installed v 3.4.6 Build 6 and it is now working. I used SQL Express installer this time instead of connecting to a stand alone sql server. Not sure if that made any difference.

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.

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: [image: dMRjlvp.png]

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

Looks like this has been fixed in 3.2.0. Thanks guys!

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

The GetUpdates() method is now included in v3.2.1

Fixed! This is included in v4.6 of the NuGet extension, which is now available.

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.)

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.

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!

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.

Thanks Philipp, we've identified some additional performance issues as well and will plan to release a maintence ProGet release to fix this .. ideally today.

Hi, Thanks for the bug report; this will be addressed in the next release of ProGet, which is due in just a few days!

The "pre-release" conventions in NuGet is incredibly bizarre and changes from version to version. We do not recommend using it until they fix it. If you want all the packages to be pre-release, then you'll need to recreate all of the package files (name + nuspec file).