Thanks!! Works like a charm

Dismiss my recent answer It works fine At some point the connector was removed from the feed which explains why nothing got listed even though the connector was fine. I'm really sorry for this! Thanks for the support!

Thank you for the report - this will be resolved in v4.0.7 due out later today.

Today it's working fine. So definitely a temporary outage on nuget.org.

Yes, please see the Get the Complete List of Connected Feeds Using the ProGet JSON API tutorial for a walkthru of how to use it.

Thank you for the report - this will be resolved in v4.0.7 which is due out later today.

RE: Retention Policies - those checkboxes are filters against the set of all packages, so if none are checked, then all packages would be deleted. Each checked box adds an additional restriction to or limits what would be deleted.

Caching is desigend to be transparent, so this is not currently an option. Of course there are a handful of ways to accomplish the behavior using a script, custom package store, package adapter via SDK, etc., would appreciate you sharing the method you use :)

Has .lib files been tested as yet? We are experiencing the same problem with the source server. Can we please get confirmation if this is supported?

I'm not sure what http://SERVER/ is? Is it a NuGet.Server instance? In that case, then http://SERVER/ would be the NuGet API endpoint. That's what you need to enter on ProGet. /api/v2 is the default endpoint on NuGet.org.

Sure, here are the main ones as of v4.0.6 which we released ealier today: OData output caching may be optionally configured in Advanced Settings that should improve package installation performance since the NuGet client (both .exe and VS extension as of v3.3.0) always issues 2 identical requests when querying for package data or downloading packages ProGet now respects the NuGet client's Accept-Encoding header which has recently added gzip; this may reduce package download times considerably Currently, the biggest bottlenecks on performance are related to connectors reaching out to NuGet.org, especially when combined with connector filters. Connector filters especially may cause slowdowns if the connected NuGet feed does not optimize the OData "startsWith" filter. In a future version, we are planning to have scheduled tasks index NuGet.org so that connectors can be filtered in ProGet's database, which will be instant in comparison to a basic 3-filter connector query.

Update! This has been fixed in ProGet 4.0.6

Thanks Alana, I will have to run the install as a service account to make sure it has access to SQL. I didn't expect it connects to SQL server as it unpacks the resources. So, it didn't cross my mind that this would be an issue. I have not yet validated if the issue is resolved, but I am 99% sure it will be. I will reply to the post once I confirm it.

You can mirror ProGet feeds, but we don't have a Maven <> Maven repository option just yet.

Although we do not provide a reseller discount, we do work with quite a few software resellers who purchase on behalf of their clients, as those clients prefer to have a single source for all procurement. If, as a reseller, you purchase directly from the MyInedo portal, just contact us with the end-user information, and we will update the licensing information. You can also submit a quote request as needed.

Wow, great find :) This will be addressed in the next maintenance version.

You could use a different workflow (or in v5, "pipelines" as they will be called)... and then have a different build importer/feed on each. Alternatively, you could not use the build importer, and just have a build step download the package and incorporate it as an artifact.

npm does not support Windows Auth. Unfortunately IIS/ASP.NET does not allow for some things to be Anon, some things to be Windows -- the whole site is one or the other. Best workaround is to create two IIsSites on the site server with different ports. You can point both of them to the same application directory. Note this does not require a separate license because it's considered the same instance, and largely a workaround for the authentication problem.

If the app can't access the service, it seems like it shouldn't assume everything is OK, but rather indicate that it has no idea because it can't access the service. :)

To migrate ProGet to a new server is as follows: If you're using a local database, back it up and restore it on the new server If you're using a local package store, copy those to the new server (ideally same exact path) Install the same version of ProGet on the new server, pointing to the new database Change whatever IIS settings you desire From the web app, edit whatever settings may have changed from the Admin section