This appears to be the same bug as reported in this question. We'll have the fix available today. Thanks for the bug report!

We've reproduced this and implemented a fix- we'll have v3.3.3 available today to resolve this issue. Thanks for the bug report!

Thank you, REPLACE works as intended.

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

Glad to hear it! Thanks for letting us know.

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,