This is not a very common scenario, so I would suggest altering your workflow to not always update the packages if they don't change. Alternatively you'll need to add some custom steps such as deleting the package before pushing it, or using a custom package store.

It looks like that particular package has a .nuspec file that does not match the name of the package ID. If you change the name of the nuspec file inside the package to match the package ID it should be able to be indexed. We will add a better error message for this in the next version.

We don't have one.... for now we're planning on featuring our deploy features in v3. Any suggestions or things you think we should do?

I believe this is a bug in NuGet; https://nuget.codeplex.com/workitem/4050 If not, I would suggest to do a fiddler trace to see specifically which url is failing,.

We had considered this feature when designing ProGet, but ultimately didn't implement it. One very popular workflow is to have BuildMaster push the packages to different feeds based on environment. Have you considered using that?

Yes Spaces were in all of my feed names. Removing the spaces resolved my issue. Removing the spaces also resolved the issue where the Download button was not working which I had reported in another thread. Thanks.

I get the same error with nuget.exe 2.7,2.6 and 2.5. We hope you can fix it in future version

There is no current way (as of 3.0.0 beta) to do this built-in, but could be done with an extension. A feed adapter is probably the best way to handle this. I'm not sure what you mean by the 2nd half of your question... you don't have to pull the package to download it from a connected feed - there is a download button just the same as if it was in your private feed.

The exact process is detailed on the page used to switch over, but here are some troubleshooting ideas: ensure both Windows Auth & Forms Auth enabled for the website ensure Anonymous Authentication is disabled ensure there are administrator privileges granted before switching perform an iisreset on the web server if using IIS

Yes, and we have actually already implemented it for our next release :) We're thinking of releasing a beta version of 3.0 today if you want to be on the lookout for it.

Thanks for the report! Just update the site to fix this.

I must be missing something here, but if you remove the View Only privilege to download packages, you should be forbidden from downloading packages... Are you saying you removed your View Only privileges, or that you removed them from the Anonymous User such that it has no privileges? If it's the latter, can you send a Fiddler trace containing the requests that Visual Studio extension is attempting to send?

Yes, all good. That directory is monitored for changes, and when a change occurs, the contents are re-indexed.

I just restarted the service and now it's showing the new version...

Tod's answer gave me something to look for. The IIS 7.5 did not have ISAPI enabled so after doing that the proget site worked as a charm. Definitely something that is missing in the documentation! For further reference see below: To enable ISAPI in the IIS look here: http://www.iis.net/configreference/system.webserver/security/isapicgirestriction at the part Setup The <isapiCgiRestriction> collection is available only after you install the CGI or ISAPI Extensions modules on your IIS 7 server. You cannot install it independent of those features. WINDOWS SERVER 2008 OR WINDOWS SERVER 2008 R2 On the taskbar, click Start, point to Administrative Tools, and then click Server Manager. In the Server Manager hierarchy pane, expand Roles, and then click Web Server (IIS). In the Web Server (IIS) pane, scroll to the Role Services section, and then click Add Role Services. On the Select Role Services page of the Add Role Services Wizard, select CGI or ISAPI Extensions. If the Add role services dialog appears, click Add Required Role Services. (This page appears only if you have not already installed any prerequisite role services on your server.) On the Select Role Services page, click Next. On the Confirm Installation Selections page, click Install. On the Results page, click Close. After doing that i restarted and did not have to any further setup. Loading the site just worked. Inedo should make it much clearer in the documentation that this must be installed in the IIS for proget to work. Just setting the App Pool to Classic is not enough. Thomas

There is no way to tell from that error alone what the problem is. Some questions to help troubleshoot: is the other feed also a ProGet feed, or some other type of a feed? Can you actually browse to and get packages from that other feed? Can you connect to the NuGet.org feed from the feed that current has the broken connector?

In this case, you should install ProGet to IIS (it's an option in the installer), and configure SSL from there.

Are you still experiencing this problem? The ProGet service is very lightweight and should startup almost instantly, though it's possible that the database connection is what's taking the time. Could you try running the ProGet service interactively? (Make sure to stop the service and run the ProGet.Service.exe executable) This will give instant logging feedback and detail any errors or connection slowness as it happens.

Setting up ProGet in what is essentially a load balanced environment is detailed here: http://inedo.com/support/kb/1073/load-balanced-and-high-availability-installation-of-proget. Note that this type of setup requires at least 2 ProGet Enterprise licenses (one for each server node). That being said, ProGet itself does not handle synchronization in the manner you described and symbol/source serving is not designed to work for connected feeds. If you wanted to sync ProGet servers manually, all you need to do is copy the packages on disk from one feed to the other.

To install ProGet, you must be an administrator and have db_owner privileges against the target database.