ProGet is licensed per server, so you need a separate license per server. We do permit temporary using the same key in the case of moving servers, etc., but only if they're used in a temporary state and decommissioned soon.

I did try that and it works outside Docker where it just uses the user that is running it. Within Docker though I can't get it to work. I tried giving it creds or api key and it just won't validate. On proget it never shows an attempt when it's the api key either. Anyway, this work around is working so now i'm progressing. I'll pass on the details once I have it working. Thanks.

I'm afraid you are simply producing invalid packages. Per the NuGet specification, a package id "may not contain spaces or characters that are not valid for a URL" ProGet could validate better on upload, but ultimately you need to stop producing invalid packages if you want to use them in TFS, VS, etc. Even if ProGet supported invalid packages, it's highly likely that those tools won't, and will stop working all of a sudden.

Licenses are activated against a particular machine, but they are not attached to that machine. If you transfer the license in the manner you describe (install on new server, uninstall on old server), then it's in compliance.

In order to prevent inclusion of prohibited licences, you will need to have all dependencies pulled through ProGet feeds to prevent them being downloaded in the first place. This also serves as a quality gateway, to ensure low-quality packages/components aren't introduced into your projects. You can enforce this at the build server (for example, with BuildMaster): simply have your build server always use ProGet as the only dependencies source, and this way if developers try to bypass ProGet, it simply won't build.

Thanks very much, Scott. You helped me by mentioning that the feeds themselves also need to support SemVer 2.0. I wasn't aware of that fact. So I just migrated our feeds an now everything works fine.

Hi Alana, Thanks for the information. I've reinstalled ProGet and IIS several times and at attempt four it suddenly worked fine. So I'm not touching the setup anymore and will keep it as-is now! Thanks, Eelko

Please check the Symbol and Source Server; basically you will want to use a symbols feed. The /symbols endpoint is not a Nuget feed, so you can't push packages to it.

Hello Mickael, ProGet does not support SSL on its own. However, if you have a reverse proxy like Traefik or nginx, you can terminate SSL in the reverse proxy and forward the connection to a locally-bound HTTP address. Here's the documentation for setting up SSL Traefik and nginx: https://docs.traefik.io/user-guide/examples/#http-https-with-sni https://nginx.org/en/docs/http/configuring_https_servers.html

A GitHub repository contains only code, so you will want to treat it as if it were a package you wrote yourself. This means download the source code, compile it, package it per the appropriate packaging method (e.g. npm, NuGet, etc), then upload that package to ProGet. You can use something like BuildMaster to automate this workflow.

Get in touch direct,happy to work toether on POC/implementation

Are you granting "Anonymous" the permission to view/download packages? If you remove that from the User Tasks page, then authentication would be required.

I'm not sure why that response says that (I believe it was written when ProGet was still in Beta), but it is in fact inaccurate. The rules for closed testing or DR instances is that a separate license is required as per the licensing agreement: https://inedo.com/proget/license-agreement In order to clarify this with some examples, I've added the following documentation that will release when 5.2 goes live: https://github.com/Inedo/inedo-docs/blob/proget-5.2/ProGet/administration/license.md#examples

@valeon @miles-waller_2091 @olivier @It-purchasing_9924 @entro_4370 Took a bit, but CRAN (R) feeds have arrived https://blog.inedo.com/inedo/introducing-cran-feeds-in-proget/

Thanks for the suggestion, I've filed this to be done here: https://github.com/Inedo/inedox-inedocore/issues/112

You can host ProGet in the cloud (AWS or Azure), but Inedo does not offer hosting of ProGet at this time. It is on our future roadmap, but there is very little interest it based on previous research.

The steps are outlined here: https://inedo.com/support/documentation/proget/advanced/cloud-storage

Thank you, in my case this is an internal Nuget package that is deployed directly to Proget. I unlisted a package version in Proget and I see the listed property is false via fiddler but it still shows up in a visual studio search. By the way, I just created a new topic for my issue here. https://forums.inedo.com/topic/3514/unlisted-package-version-still-shows-up-in-visual-studio

I found my mistake I had to specify the "Feed API user" in the API Key configuration.

I took a while to get back to this thread, but here goes: Today we upgraded to the MSSQL backed version of ProGet, that is currently on the Docker hub (5.2.9.11), and most of it went smooth. However, when restoring all the packages, I did get the unresponsive errors again. But this time the server came back and we could see the log messages. After changing the connection string, things seem to be more stable now when doing a full restore. The new connection string has this appended to it: "Max Pool Size=200;" Hopefully this version keeps us happier, as the old version needs a reboot every other day.