That's great! Thank you Jhon.

Thank you very much for your precision. I realy appreciate it. I personaly work with non conterize Postgres database in order to avoid data corruption issue; but I understand your make this decision. Hava a good day, Mathieu HOFERT

Hi Anderson , Of course, a lot of our customers host ProGet in the cloud, and just install it on their own server in the cloud. But, we found it wasn't so popular to pay us to do that. The pricing was basically hosting costs + license costs + overhead, so something like $150/mo, depending. We stopped offering it, because we found most customers were either looking for a cheap, multi-tenant service (like $20 to $50/mo), or for really advanced infrastructure far beyond our capabilities (like dozens of servers globally linked, at like $10k/mo+). We are planning to launch “bring your own license” VM/Container in the cloud services at some point, and may leverage that as a hosted option. Any datapoints or insights you might have are always welcome, and I’ll share those to our leadership!

Eventually, but we haven't had too many requests for it :) If this is something you're interested in, we'd love to partner with a customer or two to help get this developed.

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.