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.

I kept saying it couldn't find the package. Would you provide me the solution how I can go by getting this to work in Proget env? Thanks!

That particular endpoint is not listed in the metadata for the NuGet API (https://www.nuget.org/api/v2/$metadata) so it is not implemented in ProGet. We may be able to add that at some point, but the best bet for paket would be to query the versions using the standard Packages endpoint, i.e.: /Packages()?$filter=Id eq 'packageName'&$select=Version

I was only able to reproduce the difference in packages returned when the casing of the id was different than the actual ID of the package, i.e. for jQuery: http://proget/nuget/Default/Packages?$filter=Id eq 'jquery' and http://proget/nuget/Default/FindPackagesById()?id='jquery' The Packages endpoint does not return remote packages because searching in this manner is case-sensitive, while it is not for FindPackagesById. The solution seems to be always use FindPackagesById, or use /Packages?$filter=tolower(Id) eq 'jquery'.

ProGet's remote connectors only apply to NuGet endpoints, and will not connect to UNC paths like Visual Studio does. You can however simply create another feed, import all the packages in the UNC path into it, then set the feed storage path to that UNC path.

This is a known issue in the NuGet client v3.2; it does not support integrated authentication (i.e. 401 challenges). This is supposed to be resolved in NuGet v3.3.

Yes, but that's because project.json is used client-side; ProGet is really only sent the package id and version, not the project file.

I would suggest to reset your admin password using the ProGet.Service.Exe, there is an option in there. And then try to set-up LDAP again.

I see, while that works for some projects, not all of our projects uses a build server which complicates the process of deployment. Thanks

We don't have a tutorial or guide on creating one, but it basically just involves making a UserDirectory class, and then implementing the methods. Note that in BuildMaster 4.9, we changed the interfaces a bit to be more inline with ProGet. You can use a disassembly tool to see how the current ones work, or request the source.

Yes, but note ProGet is licensed for each server it's installed on, so if you keep both servers active, then you'll need an additional license.

It's only a UI issue that's preventing the checkbox from being displayed. Here is the workaround click on the Configure Symbol Server link check "Enable symbol and source server for this feed" uncheck "Strip symbol files from packages downloaded from this feed" uncheck "Enable symbol and source server for this feed" Save

You can either: not grant Anonymous any privileges (Anonymous does not belong to any groups so it doesn't have any by default) specifically add a Restriction to the Administrator role for Anonymous (this actually means Anonymous is restricted from performing any tasks that an Administrator could do, which is all of them)