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

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. :)

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 :)

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.

That's great news ! Thank you for following up :)

It looks like the underlying error is, DirectoryServicesCOMException: A local error has occurred. It's obviously not helpful at all, but in searching for that exact text, there are so many things that it seems to be, or could be. I would suggest to search for that error and see what is relavent, and what isn't. There are so many suggestions on how to fix it, from improperly configured AD permissions to obscure 2008R2-only settings.

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

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.

Great! Thanks for the quick turnaround.

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.

That shouldn't cause a problem. But you can verify it by disabling the group with your batch file calling, and then replace it with the sleep action,

Tod, Thanks very much for this piece of info and the source. Very useful. I've been able to do complete my extension, working all good!

Thanks Jon, I can how that was ambiguous! I've now updated it w/ more accurate info.

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.

So I stand corrected. This just doesn't work for me. I have an application variable set for the BUILD scope, it's a string with the other variable of $MajorVersionNumber in it and it will never get expanded regardless of how I use it. Is this variable not available during Build? It's marked as a Release variable which I took to mean anytime during the entire process, build, deploy, etc.

update, I have found that after I have Deployed the app to our Development plan I can now see the links to the reports on the that build page. However they do not show under the Build plans results page which is where I would also expect them to appear. Still nothing showing on the applications Overview page either.

The Publish action (for NuGet extension v4.7.1) requires that the URL is entered into the action itself (Server URL property) or it uses whatever is in NuGet.config, it doesn't fall back to the server URL specified in the configurer.

Thanks for the report, I logged this as an issue to further investigate... PG-492