ProGet works great with NuGet client v3! As far as the "protocol" is concerned (i.e. ODATA vs JSON-LD) the "v3" protocol is intended only for use by nuget.org and nuget client. It's not documented by Microsoft, unstable, and they have no plans to document or support it. Since the "v2" protocol (ODATA) works just fine, we are not going to reverse engineer the "v3" protocol or otherwise use it.

Thanks for the help investigating this. We've identified a possible race condition during initialization, specifically involving discovering the connection string of the currently installed instance. The presence of .NET 2 shouldn't affect things, as the installer specifically targets 4. The 20 in the CLR20 error just refers to the runtime version. .NET 4 runs on the CLR 2.0 runtime, confusingly enough. We've made a small code change which should resolve this issue - assuming it is the cause. We haven't been able to reproduce it on our systems. The installer for the next version (which should be 3.6.2) will have the fix, so you may want to try using the larger installer again just to see if the issue goes away. You never need the full installer to perform an upgrade, however. Again, thanks for the help!

If you're seeing this message, then you'll need to ensure ASP.NET4 is installed -- not just .NET4 and .NET4 Extensibility. It's a separate option (that's kinda hidden).

You will need to use Fiddler to determine the EXACT urls that are causing a problem during package restore; we can then investigate what query is causing the problem.

I can't believe I missed that. I upgraded and that problem is gone but with new issues. Will open a separate question for that problem. Suggestion: How about adding a new tag npm? Thanks Niklas

This error means that the connection string in the installed product doesn't work for the user installing the software. Most likely, you don't have access to the database or server. I think the discussion here http://inedo.com/support/questions/3126 may be related as well.

The basic process is: Install the exact same version of ProGet on the new machine Backup the ProGet the database and restore it onto new machine over the new database that was created by the installer Set a bulk import path for each feed Copy the packages from each feed into the corresponding bulk import path of each feed Allow a minute or so for the indexer to pick up the new packages and add them to the feed

Hi Simon, If those buttons aren't lighting up, then the machine doesn't have internet access and can't request a key. Just go to my.inedo.com and request one instead, then enter it in. You don't need to manually install, but FYI that zip file would be in the manual installation package.

The current behavior is to never overwrite existing packages during a bulk import. Maybe we should add a configuration flag for this- at the very least I'll make a note to update the documentation to describe this behavior.

Hi Dan, we don't offer any additional pricing options; although we do provide licenses for free open-source projects.

Here is the "draft" list that will be posted on the website soon (Free, Basic, Load Balanced, High Availability): Features F B L H Unlimited Users X X X X NuGet Server X X X X NuGet Package Symbol Server X X X X Chocolatey Package Server X X X X npm Registry Server X X X X Bower Server X X X X Maven Server (beta) X X X X License Filtering X X X Connector Filtering X X X Feed-level User Privileges X X X Active Directory Integration X X X Package Retention Policies X X X MyGet Feed Synchronization X X X Package Statistics X X X Custom Licensing Agreement * X X Multiple Web Servers X X Multiple Index Servers X Automatic Failover X * w/ purchase of 5 or more servers

I'd be interested in this feature as well. We want to use the NPM registry but prevent developers from pulling newer versions that haven't been tested with our software. We'd also like to block on major, minor and patch revisions. Thanks

Ah! That would explain why I couldn't reproduce this. I forgot that some versions of npm did weird things with URLs... Glad it's resolved!

Thanks for letting us know; we're currently waiting on the NuGet v3 API to be released before spec'ing this out further. It's scheduled to ship with VS 2015 later this month, so we'll have a better idea after that. It used to work, and it still kind of does depending on the time of day... but NuGet.org's performance has degraded significantly over the years. Now it's very hit-or-miss, and the longer the package filter list, the higher the chance your connector will time out.

That option unfortunately will not work at this time without significant changes, and it's supposed to be hidden currently. We may remove it in the next version or add the required functionality to get it working in an even later version. The problem with it is that dependencies can now vary based on other factors such as platform, .NET Framework version, etc. As a workaround, enabling caching for the feed and downloading the package from Visual Studio will accomplish essentially the same thing, though.

Please see: http://inedo.com/support/kb/1021/using-proget-with-nuget-the-visual-studio-extension

Retention Policies are not inclused in the free edition. You can still delete packages manually however.

Another quick way you can close all connections to the database: ALTER DATABASE [DbName] SET OFFLINE WITH ROLLBACK IMMEDIATE ALTER DATABASE [DbName] SET ONLINE

It was execution time in web.config. Thanks for help!

Thank you for the report, this will be resolved in the next release.