This is a known issue with the native API. The behavior is certainly not desired, and we are planning to develop a new feed management API in the future, so we will address this issue at that time. in the meantime, please be careful when using the Native API; it's a low-level API and doesn't always validate like you would expect. Note you can also delete the feed using the NativeAPI if you accidentally do that.

There is an ountstanding feature for this, and you can follow the progress here: PG-1331

What errors are they getting? Almost all non-certificate-related issues with HTTPS are related to forcing TLS v1.2 support. See this thread for more information and a resolution: https://inedo.com/support/questions/8831

Basically the error message is saying that the client (it appears, your web browser) cancelled the request halfway through completing it. You can reproduce it by, like requesting the URl and quickly closing the browser, or hitting back button, or something. It could also be intermediate equipment that cancelled the request, too. Basically the error means that the response could not be sent because the server can no longer talk to the client(browser). There's no other information that the web server (IIS, in this case) can know. It's not uncommon for a loadbalancer to do this, and you can generally ignore this error in the diagnostic center.

The problem comes from the anonymous user, after allowing anonymous users to publish on the proget server it works Sylvain

Hi Martin, Thanks for reporting this problem. We do make the standard (old) installer available as well so it can be used in case of bugs like this with the new one. We will issue an update for InedoHub to fix this, but for now you can still use the old installer (available here under the "Traditional Installer" links).

The problem was solved when remove dash from package name.

Please refer to the Upgrading Extensions section of the v6.0 upgrade notes.

This error indicates an incomplete request is being sent to ProGet; typically it happens from misconfigured client that is not authenticating properly.... but it's really hard to guess from that error message alone. Unfortunately I'm not familiar enough with how to configure TeamCity to advise on how to fix this. Perhaps cross-post this on their support forums as well.

This error message is coming from the NuGet client, and it's regrading your server's SSL configuration. Unfortunately I don't have enough information about your server or network configuration to tell you how to begin troubleshooting, but if you search that error, you can find lots of tips on how to ensure you have certificates set-up properly, etc.

Assuming you don't any server misconfiguration or SQL Server latency issues, then the biggest performance bottleneck tends to be the network. Each client/user will make dozens or hundreds of simultaneous requests, often using machines more powerful than the server, and these requests can be expensive... particularly if you're using connectors... because they have to be forwarded to another server. These requests "pile up" and eventually, the underlying infrastructure can't handle it (IIS, network card, etc), and you start getting timeouts like that. This is where load-balancing comes in, and is pretty important in your configuration as you add users and packages. See How to Prevent Server Overload in ProGet to learn more.

I was finally able to go through the source code to see that the menu option was in fact missing in v1.0.3 - I don't know how I missed that you were on that version vs. the one I was using (v1.0.4) :( An upgrade would solve, but I also see your ticket and will prod a developer to take a look at that for you as well and get out a new hub installer with the improved debug logging.

For the Windows service, the only requirements for the service account are (assuming default file system package store configuration) read/write access to the directory where the underlying packages are stored (default is in ProgramData), read/write access to the service installation directory (default is in Program Files), and granted access to the ProGet database role named ProGetUser_Role. For the web application (Windows service or IIS application pool identity), the requirements are the same as the Windows service, plus read/write access to the website installation directory. Note again that the Desktop Hub installation privileges is orthogonal to the account that ProGet runs as, since it would obviously require more privilege to create/update/grant in the database and also create subfolders in Program Files & %ProgramData%. As an extra word of caution, if D: is a mapped drive, be sure to use the full UNC path in configuration settings within ProGet.

"Windows Authentication" is built in to Windows (web server), and is happens below the application layer (i.e. ProGet). It's by design (Microsoft), and the intention is to use domain/service accounts to control access. I'm not sure I see the security hole to be honest, since pushing to a feed isn't that sensitive of an operation. Just don't let these users overwrite/delete packages.

Update: I've filed this bug with Docker: https://github.com/docker/distribution/issues/2649

This is a feature of the paid edition of ProGet; once you have that, you can scope security tasks to specific feeds. Otherwise, everything is global.

Ok, I use this KB 2 days ago and i added netbios name, fqdn but same problem. I try to change the user context but same pb. Error 503 - service unvailabable I will change my stack of web and i will go to install IIS...but is strange for an editor to indicate don't use "web integrade proget server" Thanks.

Hello Steven, Try visiting this page in a browser: http://<ProGet hostname>/feeds/<feed name>/NuGet.Frameworks/4.7.0-rtm.5148 There should be an error message like this: The version number provided is invalid, but would be valid if this NuGet feed were migrated to SemVer2. You can migrate a legacy NuGet feed to SemVer2 by clicking the button at the top of the feed management page.

TFS labels can be a bit complicated, and the way that Visual Studio (GUI) vs tools (tf.exe, BuildMaster, etc) interact with them are different. What may be happening in the GUI is that multiple labels are being created with the same name, and the the GUI is "searching" for files by label name (as opposed to "getting" those files). If you were to do a tf.exe get (https://docs.microsoft.com/en-us/vsts/tfvc/get-command?view=vsts), for example, you should see the same behavior. Instead, makes sure to first create a label at the $/ root level (e.g. tf label myLabel $/ ), and then you can sub-label items.

Turns out I needed to migrate the feed to the "new format" that supports semver. Everything worked like a charm afterwards. Thanks