The -source argument doesn't look right. Since the command is running remotely, it shouldn't be accessing localhost, but instead it should be using the ProGet server's URL. To override that URL, make sure to set the ODataBaseUrl in Advanced Configuration to something like: http://proget-server:1000/nuget/

This error is coming from nuget.exe; depending on the version of nuget.exe you're using, AD / integrated authentication simply will not work. It's supposedly fixed in 2.8.2, but some users say it doesn't work in 2.8.3. It's pretty broken in 2.8.1 and 2.8.0. Although it sometimes works in 2.7. The 2.6's seem to be fine, for the most part. ProGet.exe, from the now-defunct client tools, of course will work fine, or a simple HTTP PUT operation.

Have you looked at ProGet's deploy features? We switched to using those from Octopus, sooo much simpler for our configuration (no agents... plus we could just do a choco install if we needed to), and you could add w/e pshell scripts you wanted.

Just wanted to let everyone know who's affected by this that we have a fix in 3.5.0. It's officially classified as a beta version, but only due to some database schema changes. The release notes and download links are here: http://inedo.com/proget/versions

Guess it depends on the project. I removed -IncludeReferencedProjects on another project we have and that did resolve the issue. Seems to be that if the SRCSRV: {path}\src{ProjectName}{file}.cs not indexed error message contains the project name after src\ then you need -IncludeReferencedProjects. Maybe?

Yes. We can switch to IIS. Login time out is not a problem. The problem is that our CI builds were taking much longer depending on ProGet needing to spin up. I'll let you know how it goes.

This depends on the setup, if you use Integrated Windows Authentication, you cannot have anonymous access to any feeds because the authentication will be required before the request even hits ProGet. However, there is an option on the "All Settings" page named "IntegratedAuthenticationEnabled" that when set to false will allow you to use the Forms-based approach using your Active Directory credentials. Another option with regard to the build server is to just copy the .nupkg files on disk to the feed's storage path, which will in turn be picked up by the indexer and added to the feed.

That's a good question! Currently, the web interface doesn't use any of these adapters (as you have discovered), but in an upcoming version, we are going to change the way package upload/indexing works behind the scenes and will incorporate the adapter at that time. As far as scheduling that goes, we're aiming for v3.3 to be released in the next couple of weeks.

Just add the feed as per normal and when you want to add or update packages, Visual Studio will pop up a message box that allows you to enter the credentials for the feed when you select "Manage NuGet Packages..." or "Manage NuGet Packages for Solution..."

I'm guessing that your AAA.BBB package does not have a .nuspec file in it, or it is not named AAA.BBB.nuspec. This behavior hasn't changed since 3.1.0, but it's possible that it just didn't used to get logged before. You may want to open up the .nupkg file in package explorer or a zip utility to check it out.

That value is in seconds. For the performance aspect, it should be relatively fast with your number of packages. Do you by chance have a wildcard connector filter configured for the feed? That is what typically adds the most time to package requests, as the requests to the connected NuGet feed end up using the OData "startswith()" function which is not the most efficient. Otherwise, if you don't have a connector filter and are experiencing slow downloads, once the new indexing method is implemented (scheduled for v3.3), the delays should go away completely and you shouldn't have to restart the service. As implemented now, there is a FileSystemWatcher that monitors the entire package directory, which can do strange things with lots of files, especially when the packages are stored on network shares. In the new version, it will monitor only an empty drop folder, and once packages are put in it, move them into a subdirectory format like "/package/{version}/{.nupkg-file}". We are beginning development on this feature starting today now that our v4.5 of BuildMaster has been released, so keep an eye out for the next minor release. Note we may actually add this feature to a maintenance release of v3.2 without formally announcing it, so check the release notes to see if it's included.

Can you try updating to v3.2.1 (the newest at the time of this writing) and see if your issue is resolved? http://inedo.com/proget/download

The error is either on nuget.org's end (possible, but will go away within a few minutes) or within your network (most likely). If you have a proxy server or firewall, make sure it's configured to allow passthru SSL connections; keep in mind, default port is 443 for this... for the user that the ProGet service/web-app is running under.

You can reset the Admin user account password by stopping the ProGet Windows service, then running ProGet.Service.exe and selecting the "ResetAdminPassword" option. Make sure to restart the Windows service when finished.

Your best bet would be to run a fiddler or similar trace to see what calls monodevelop is making vs visual studio. There is really no documented standard API, so it's very possible that monodevelop is using something that happens to work with nuget.org,

It actually always makes the reservation, though once the service is installed you can immediately remove it with the DeleteReservations command in ProGet.Service. I believe we did this originally to make it easier to switch back and forth between IIS/integrated, but I agree that this should be optional at least, and I will file this as a bug.

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!