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)

Maybe you want to write an Extension for ProGet that is invoked whenever a apackage is pushed to a certain feed. Once triggered, you cando whatever you need to do in your extension.

Hi Matt, I would suggest to attach fiddler, and see what's going on. That XML you pasted is what a NuGet endpoint looks like; from there you can append /Packages to the URL, and see more of the exposed API.

ProGet is currently on-prem only, though you could install an instance in the cloud quite easily (a lot of people do that). We will likely have a SaaS/hosted version in middle of next year.

The Active Directory user directory has since been open-sourced here: https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/InedoExtension/UserDirectories/ADUserDirectory.cs

Based on the message, it would appear the registry is not pointing to ProGet, but is instead pointing to npmjs.org. I would do a wireshark or fiddler trace to see where it's actually going, and note what's being passed through.

I get the same result with versioin 4.5.1. I try to change the connection string during the install but it still uses the default connection string and not the one I entered. I also tried to set it using the silent option. Then the installer fails without any message at all, not even to the specified log file.

Unless something has changed, you cannot use Integrated Authentication with npm because the client doesn't support it: http://inedo.com/support/questions/2647 However, if you enable LDAP authentication in ProGet and then disable Integrated Authentication, you'll be able to use your Windows credentials. If it's the backslash that isn't supported, try the Active Directory provider, which supports the user@domain syntax.