Thanks for the report. We'll have this fixed in v4.5.4, which will likely be available today.

To downlad a package, you'd need to use the feed-specific API (NuGet, npm, etc). The SDK is really only designed for building extensions.

It would be nice if you could avoid this error? It's filling up the error log, making it hard to find the actual errors.

Discussion should be moved to a new post or followed here: http://inedo.com/support/questions/6554

I ran into the same issue when trying to run image on docker on windows (in linux container of course). First thing that I tried was to turn off proxy server. After that, instead of seeing an "Activation completed" message, activation request never finished. In the end I restored original proxy settings (same as system), restarted docker image and activation went without any issue automatically after restart.

If you are getting a browser pop-up authentication (as opposed to a ProGet login screen), then it means Windows Integrated Authentication is not working. This is due to configuration of your server or domain. Unfortunately, this is performed by IIS/Windows (not ProGet), which means the request is never reaching our software; this means we can't provide any information about why it's not working. But this also means there are a lot of resources/articles you can find to give debugging on how to get it to work. I would suggest searches like, "Windows Integrated Authentication always authenticates" etc. Please post what you find!

I found this thread after experiencing a similar issue. I was seeing the "string is not a valid semantic version error" from Proget when npm would try to install scoped packages, but only when the npm install was automatically triggered inside Visual Studio by a change to the package.json. We already had the latest version of Proget with the change to the web.config and installs worked fine when running from command line. Problem turned out to be the fact that Visual Studio 2015 had installed it's own copy of the npm.cmd as an external web tool. This was an older version than the one I had installed globally, but the order of external web tool locations in Visual Studio had the path to the older version listed before my system path. Making system path take precedence solved the issue. Just thought I'd post this here in case anyone else with a similar issue stumbles across this thread like I did.

SOLVED Human error on my part. Thought it best to state this so that others don't waste anytime on the thread.

Currently the license filtering is only supported for NuGet-feed types, but we are planning on a license management module coming soon that will handle this much etter for npm and other feeds.

This regression was fixed in ProGet v4.5.0. I'd recommend upgrading to the latest version.

It's likely that the user installing does not have the ability to access the database defined in the configuraiton files on disk. So, make sure to run as a user that has DBO on those databases.

Thanks!!!!!! That will help a lot.

When you un/re-install ProGet, it will not delete the database unless you explicitly say to. If you run the service interactively (just run the ProGet.Service.exe), there is an option to reset the admin account permissions.

SOLVED See the following Stack Overflow question fro the solution. http://stackoverflow.com/questions/3853767/maximum-request-length-exceeded In summary: in the web.config <configuration> <system.web> <httpRuntime maxRequestLength="2147484" /> </system.web> </configuration> and <system.webServer> <security> <requestFiltering> <requestLimits maxAllowedContentLength="2147483648" /> </requestFiltering> </security> </system.webServer> Note: maxAllowedContentLength is measured in bytes while maxRequestLength is measured in kilobytes, which is why the values differ in this config example. (Both are equivalent to 2 GB.)

We'll consider it when revising the UI/homescreen (we don't , but most package managers do seem to report the total (not unique)...

Found the problem: It was an incorrect credentials at the connector.

I've managed to get this working in v5.0.11 by setting up the second ProGet website in IIS with anonymous authentication enabled and pointing to the same physical path as the original website. The same AppPool is shared between the two and is using the Integrated pipeline. No other IIS or .config configuration was required. In ProGet, for the npm feed that required anonymous access I added the Anonymous user to the feed permissions under Administration > Security > Users & Tasks. Restarting the web services then enabled the anonymous access to the feed using the second website's bindings.

You may have luck grabbing the packages from the internal, disk-based package store, and copying those to the drop path on the new server.

That did the trick! Thanks for the hint.

You can fairly easily switch directory providers, so you could just try that and see if it works. A lot of organizations will have a dedicated ProGet test instance (note this requires a separate server license) to test upgrades and major configuration changes. For most organizations, both LDAP and the Multi-domain configuration "just work". So long as service account running the ProGet web application has the appropriate permissions to query, and the domains are set for proper trust, then users will be retreived as expected. But for some, it doesn't, and the only way to find out why is to do a detailed analysis using our code. 90% of the time it's a domain configuration problem. But there's no easy way to identify it because the AD libraries do not tell us why certain users or their groups are not returned in a query.