We experience this issue very often..

I implemented a VS2017 credential provider that reads NuGetDefaults.config and passes the credentials. But it's always passing the same credentials as the first feed that is accessed (we have multiple feeds that require credentials).

So it seems that Visual Studio/default browser/CredentialProvider is caching the credentials for that domain.

We're running ProGet on IIS with no permissions for Anonymous users and have a NuGetDefaults.config file configured with packageSourceCredentials (https://docs.microsoft.com/en-us/nuget/consume-packages/configuring-nuget-behavior).
Yet we get a prompt for filling in credentials in Visual Studio all the time (both in Visual Studio 2015 and 2017) instead of reading them from the config file.
As I read in other support questions, the problem is that at first there's a GET request without credentials.

Do you have any real solution for this?
If not, perhaps a ProGet CredentialProvider exists somewhere?

Product: ProGet
Version: 4.7.6

I solved this by configuring the URL including port number in the Advanced Settings at "Web.BaseUrl"

We have NGINX in front of our ProGet installation with SSL offloading.
So the traffic to the NGINX proxy is on HTTPS and the traffic between the proxy and the ProGet server is on HTTP.

This is causing issues with the URL's in the Installation Instruction section for package details.
For NuGet feeds, the URL's are on HTTP, without port: http://***.be/nuget/feedname/
For Docker feeds, the URL's are without HTTP scheme, on port 80: docker pull ***.be:80/feedname/

How are these URL's constructed? The strange thing is, when browsing to ProGet on the web server locally, the URL's are HTTPS and 443.

Is there a solution for this? The documentation says "ProGet was built to be compatible with any load-balancing platform, whether software-based (such as HAProxy, NLP, or nginx) " https://inedo.com/support/documentation/proget/installation/load-balancing-and-automatic-failover

Should we configure a Web Proxy in the Advanced Settings to solve this?

Product: ProGet
Version: 4.7.6

It's working again now, there was an issue with one of our feed URL's. But I would expected an HTTP 404 error instead of an HTTP 500 error then..

Feeds with a connector to nuget.org are returning errors (both in Proget 4.7.4 and 4.7.6):

[nuget.org-microsoft.net-proxy] The V2 feed at 'https://packages.tobania.be/nuget/packages.org-microsoft.net-proxy/Search()?$filter=IsLatestVersion&searchTerm='entity'&targetFramework='net40'&includePrerelease=false&$skip=0&$top=26' returned an unexpected status code '500 Object reference not set to an instance of an object.'.
[nuget.org-proxy] The V2 feed at 'https://packages.tobania.be/nuget/packages.org-proxy/Search()?$filter=IsLatestVersion&searchTerm='entity'&targetFramework='net40'&includePrerelease=false&$skip=0&$top=26' returned an unexpected status code '500 Object reference not set to an instance of an object.'.

Searching on nuget.org/packages/ does not return any errors.

Product: ProGet
Version: 4.7.6

Thank you! I'm no PHP developer either but the source code of Composer and Packagist is available on GitHub:
https://github.com/composer/composer
https://github.com/composer/packagist

Both make use of the Symfony (PHP) framework.

I've heard some time ago that it's scheduled for Q1 2017.
Do you have a more concrete timing on this now?

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.

On the dashboard there's a package count per feed, but this seems to count all versions of all packages.
Could you add the count of the number of unique packages per feed (no matter how many versions exist)?

Product: ProGet
Version: 4.5.0

According to the documenation this name should be the same:
https://inedo.com/support/tutorials/proget/getting-started-with-proget-private-docker-registries

However, when doing "docker push nuget.tobania.be:443/linux/php-5.6:1.0.0" the pushed package needs to be pulled with "docker pull nuget.tobania.be:80/linux/library/php-5.6:<tag>".

Why is the package named "library/php-5.6" instead of simply "php-5.6"?

Product: ProGet
Version: 4.5.0

I've upgraded to the latest version "Version 4.0.10 (Build 1)". The issue seems to be solved for the package Geocoding.net.

For our feed with inhouse developed packages the issue persists..
Packages with a "lib/net40" folder structure are visible, while any packages with a "lib/net451" folder structure are not ?

It seems that NuGet packages that were built for .NET 4.0 for example, are not queryable/visible in the NuGet Package Manager extension of Visual Studio for projects that target a higher .NET version (like 4.6) for ProGet feeds.
We noticed this issue when trying to install a package from nuget.org and from our ProGet feed connector to nuget.org.

Product: ProGet
Version: 3.7.5

ProGet still doesn't seem to support connectors for https://api.nuget.org/v3/index.json ? When can we expect support for this?

I was able to create the source control provider now and I configured a profile for the extension as well.

When I try to create an application in BuildMaster using the Deploy TFS Team Build wizard, I get a HTTP 500 error page. In the logs I see this:

An error occurred in the web application: TF30063: You are not authorized to access https://*.visualstudio.com/DefaultCollection.
 Details: URL: http://*.be:8086/administration/applications/create/recipe?recipeType=Inedo.BuildMasterExtensions.TFS.DeployTeamBuildRecipe,TFS
Referrer: http://axwinservices01.axmatrix.be:8086/administration/applications/create
User: Admin
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36
Stack trace: at Inedo.BuildMaster.Extensibility.Agents.Local.LocalAgent.Inedo.BuildMaster.Extensibility.Agents.IRemoteMethodExecuter.InvokeMethod(MethodBase method, Object instance, Object[] parameters)
at Inedo.BuildMasterExtensions.TFS.TfsConfigurer.GetTeamProjects()
at Inedo.BuildMasterExtensions.TFS.TeamProjectPicker.OnInit(EventArgs e)
at System.Web.UI.Control.InitRecursive(Control namingContainer)
at System.Web.UI.Control.InitRecursive(Control namingContainer)
at System.Web.UI.Control.InitRecursive(Control namingContainer)
at System.Web.UI.Control.InitRecursive(Control namingContainer)
at System.Web.UI.Control.InitRecursive(Control namingContainer)
at System.Web.UI.Control.AddedControl(Control control, Int32 index)
at Inedo.Web.Controls.CExtensions.Add(ControlCollection toControl, Control[] controls)
at System.Web.UI.Control.EnsureChildControls()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

The VisualStudio.com provider doesn't seem to support VSTS Personal access tokens yet?
That method is recommended (more secure) than enabling "Alternate authentication credentials", which is Basic HTTP Authentication.

I also tried the VisualStudio.com provider but that seemed to point to the TFS2012 extension upon installation and throws the following error when attempting to connect:

Provider error. Could not connect to TFS: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.TeamFoundation.Client, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.TeamFoundation.Client, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
at Inedo.BuildMasterExtensions.TFS2012.TfsSourceControlProvider.ValidateConnection2()
at Inedo.BuildMasterExtensions.TFS2012.TfsSourceControlProvider.ValidateConnection()

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Great! But no luck so far:

Provider error. Could not connect to TFS: Microsoft.TeamFoundation.TeamFoundationServerUnauthorizedException: TF30063: You are not authorized to access https://*****.visualstudio.com/.
at Microsoft.TeamFoundation.Client.Channels.TfsHttpWebRequest.EnsureTokenProvider(HttpWebResponse webResponse)
at Microsoft.TeamFoundation.Client.Channels.TfsHttpWebRequest.SendRequest()
at Microsoft.TeamFoundation.Client.Channels.TfsHttpRequestChannel.Request(TfsMessage message, TimeSpan timeout)
at Microsoft.TeamFoundation.Client.Channels.TfsHttpClientBase.Invoke(TfsClientOperation operation, Object[] parameters, TimeSpan timeout, Object[]& outputs)
at Microsoft.TeamFoundation.Framework.Client.LocationWebService.Connect(Int32 connectOptions, Int32 lastChangeId, Int32 features)
at Microsoft.TeamFoundation.Framework.Client.FrameworkServerDataProvider.Connect(ConnectOptions connectOptions)
at Microsoft.TeamFoundation.Client.TfsConnection.EnsureProviderConnected()
at Microsoft.TeamFoundation.Client.TfsConnection.EnsureAuthenticated()
at Inedo.BuildMasterExtensions.TFS.TfsSourceControlProvider.GetTeamProjectCollection()
at Inedo.BuildMasterExtensions.TFS.TfsSourceControlProvider.ValidateConnection2()
at Inedo.BuildMasterExtensions.TFS.TfsSourceControlProvider.ValidateConnection()

Name:
Visual Studio Team Services
Server:
TFS URL:
https://.visualstudio.com/
Authentication:
User name:
yannick.@tobania.be
Password:
••••••••••
Mask
Domain:
Workspace path:
BuildMaster managed
Workspace name:
Default
Options: Log command line arguments

Does this also work with Visual Studio Team Services (builds from TFS/Git/GitHub) ? (This was previously called Visual Studio Online.)

Product: BuildMaster
Version: 4.9.7

I tried adding a connector to the Default feed for the new NuGet 3.x endpoint "https://api.nuget.org/v3/index.json" that is also already used in Visual Studio 2015.
It was actually released the same day as VS2015.
This doesn't seem to work in ProGet: no packages are listed in the feed.
When do you expect to have support for NuGet 3.x ?

The architecture was redesigned, there's even a new nuget protocol version.
I'm mainly interested because it would have much better performance.

Product: ProGet
Version: 3.8.1