Unfortunately, that's not uncommon. Keep in mind the remote registry is a gigantic JSON file that ProGet downloads and then processes. What's happening is that npmjs.org is just inexplicitly terminating the connection during the download. You could be downloading it too slowly, too fast, or who knows? You can try it again, and maybe it will work. Some users have reported that downloading the file from a different network, and then hosting that file on a local server works fine.

Hi Mike, Apologies for the delay, but the problem is with the NuGet extension for BuildMaster. There is a new version (4.7.2) available that can be updated from within BuildMaster on the Admin > Extensions page.

HTTPS/Certificates are at the socket layer... below ProGet's application layer. We're not familiar enough with Bower's internals, but it's most likely just using the operating system's network stack, and reporting warnings/errors from the underlying components. Likely it's a certificate trust issue between your computer and the ProGet server, or some intermediate authority. So, while there's nothing we can do on the PRoGet side, hopefully this helps point you in the right direction.

Good question; in all package managers, a "package" always refers to unique instance (i.e. a single .nupkg, a POM, etc.). Different package managers consider uniqueness different: in NuGet, this is Id + Version in Maven, this is Group + Artifact Name + Version So, that task indicates if you can overwrite a package already added.

We don't currently have detailed documentation on all of the tasks, but it's on our list. If you have specific questions, we are happy to answer them of course! In the case of Feeds_OverwritePackage, if you do not have that task, then you will not be able to add/push a package that already exists. This is the default behavior of public feeds like nuget.org, npmjs.org, etc. -- once it's added, you cannot remove or update it.

It should "just work", but when it doesn't there are so many things that it could be. Often times, the API/libraries from Microsoft that we use to query AD simply return no results (and no error messages, either). So, you'd have to check the ProGet logs, the Windows Event logs, and Active Directory logs as well. 80% of the times, it's permissions related; i.e. the ProGet web service account user does not have permission to query appropriately.

Are you sure the requests are actually leaving your desktop? Obviously The Real WTF here is doing ONE THOUSAND outbound network requests for a contiguous operation. Since they managed to write a client that does that, I think there's no chance that they can competently build a proper network request pool, let alone one that reports proper messages. The NuGet client had a problem with this a while ago, where it was doing similar nonsense that lead to race conditions that only appeared when you used ProGet b/c the requests were being served significantly faster than NuGet.org.

So, in the free version I can't clear cache?

Do you mean from the ProGet UI? There is not currently such a feature.

Make sure that the service has started; if it's not, then investigate the windows error log to see if anything in there occur when you attempt to start it. Make sure there are no firewalls, or other tools are preventing access from that port being accessed.

The feed clean-up writes logs to the database before starting, so if you have no space left on disk, then you can't start a clean-up job.

Currently, NuGet.org's API does not support this sort of filtering, so it's not feasible for us to do this via a connector. We do have an item on our ProGet roadmap for downloading the entire NuGet.org index, which would then make such a filtering possible. In the mean time, the best and easiest way to handle this workflow is to build a "curated feed" of approved packages.

It's hard to say why there was an issue uninstalling, but to clean up, just follow the manual install steps in reverse, and Strange. It doesn't really do that much. Anyway, if you want to fully manually uninstall here's how: Ensure the service is stopped: INEDOPROGETSVC Uninstall services by executing "ProGet.Service.exe" from an admin command line in the ProGet\Service directory, and followign the prompts Delete the Service and WebApp directories, (and anything else under ProGet you don't want to keep) Delete the HKLM\Software\Inedo\ProGet registry key Delete the HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\ProGet registry key If using IIS, delete the ProGet web app and app pools If you really want to delete everything , you can also drop the ProGet SQL database

NPE has several bugs that prevent it from being used in many environments and seemingly basic scenarios, including this bug. Unfortunately the NPE is no longer maintained, and hasn't been changed in years, so it's unlikely this will ever be fixed. There is absolutely nothing we can do about it, as it's a client bug.

If you look at any package detail page on nuget.org or chocolatey.org they show "Authors" and "Owners" (packager) and in the sidebar they show links for "Software Site", "Software License". If there is an icon link in the package, that icon is actually displayed (in gallery as well as detail page). Their "tags" are also clickable to search by tag. It would be nice for Proget to be on parity with the Nuget Gallery as that is the defacto user experience. A bit more value add would be to allow me to create custom elements in .nuspec and somewhere on ProGet indicate if they display as either a main body item or a link on the left hand bar. These items would improve the browsing experience to help make it more useful as a package catalog.

Yes, good catch; I noticed that it was missing too when writing the same exact docs for the Otter Silent Installation Guide.

Note that you will need to specify the "Urls" argument when running the service, to indicate which url you intend to bind to.

There's absolutely nothing on ProGet's end that would cause symbols/source to sometimes work, and sometimes not in this manner. Async implementation in C# is very complicated and brand new, whereas source/symbols, OTOH are a 20+ year-old technology, and extremely fragile. So, this is just a bug in VS2015, where it's not loading a remote symbol. You can verify this using something like Fiddler or Wireshark, and then see that it's not even attempting to load symbols with the async debug. Please do send this to Microsoft, so they can fix it in a future update.