Hi @nicolas-morissette_6285, No problem! If you are still having issues after you reach out, please feel free to reply back to this topic. Thanks, Rich

This is unfortunately a documentation issue. We changed some of the environment variable names for ProGet 5.3 - so you'll need to use: -e PROGET_DATABASE="Data Source=proget-sql; Initial Catalog=ProGet; User ID=sa;Password=<Secret>" \ -e PROGET_DB_TYPE=SqlServer instead of -e SQL_CONNECTION_STRING=... We'll update the docs to note this for ProGet 5.2.

@rhessinger : Thanks, tested Version proget.inedo.com/productimages/inedo/progetmono:5.3.13 and it is working now as expected.

Thanks everyone for the help. -marc

No problem, ask away :) You could. Not sure what the use case would be... But, the URLs for NuGet package versions are quite predictable, and you can discover them from the Download button in the UI. For example, the download URL for InedoLib v950.0.7 just looks like https://proget.inedo.com/nuget/NuGetLibraries/package/InedoLib/950.0.7 The NuGet API does not support Bearer authentication. You can specify an API key when publishing packages (X-NUGET-APIKEY header), and it might work when downloading packages? Haven't tested, and no one asked before. But you could also specify api:<apikey> as the basic auth credentials as well, so I guess that's really easy too.

Hi @viceice, That error is safe to ignore. It is currently a known bug and we are looking to fix that in an upcoming version of ProGet. The ticket tracking the fix for the log message is PG-1841. Long story short, the ProGet service correctly detected that the product wasn't activated, and then logged that message. But it was doing it every time it accessed license information, which is on every connector health check, replication run, etc. Activation happens automatically as soon as someone visits the Web application, and re-activation is required after upgrading certain versions. Thanks, Rich

You're welcome

Just following up- all of these issues should be resolved in ProGet 5.3.13, which will be released later today.

Hello, this has finally been scheduled for 5.3.13, which is shipping tomorrow. It addresses only this specific test case, so please let us know if you're spotting other errors.

Hi Phillipe, I created an issue on GitHub, #8, to track adding this to the extension. I'll reply back once there is a CI version released of the extension. Thanks, Rich

Hi @nuno-guerreiro-rosa_9280, No problem! Gald it helped! Thanks, Rich

Hi @barnaby-williams_8489, This is just a manual copy of the files. Thanks, Rich

@rhessinger Thank you!

We have identified the regression (PG-1830) and fixed it. It will be included in this week's maintenance release (ProGet 5.3.13), but you are also welcome to try the prerelease image right now if you would like - it's available as proget:5.3.13-ci.2 or progetmono:5.3.13-ci.2. Thanks for reporting the bug!

Hi @mike-vanoorschot_1180 We check for local requests using HttpRequest.IsLocal, which basically just looks for 127.0.0.1. If it's not local, then a license violation is recorded. If the server doesn't resolve proget.xxxx.com as 127.0.0.1, then configuring BaseUrl will be a problem, especially with NuGet. The NuGet API requires absolute urls (issue #1), and many API responses are just URLS that the client (in this case, the connector) must follow to get the "real answer" (issue #2). So this will trigger license violations. If you need to specify a BaseUrl (you really shouldn't have to), then you'll need add a /etc/hosts entry for proget.xxxx.com 127.0.0.1

For this, you could just disable the connector, and use a Promoted-package workflow, where you manually promote approved packages from one feed (Unapproved) to another feed (Approved). When the request is very simple, like "give me this exact version of this exact package", then it's not forwarded. But typically the request is, "what's the latest version of this package". Of course, that must be forwarded and aggregated against all connectors. Why the client makes such a request in some cases is a mystery, but that's why they rewrote everything from scratch into a new, v3 api.

Hi @nkerifacclaud_6931, Thanks for testing this out! I will get it released as a production version today! Thanks, Rich

Hi @mikhael_3947, I have updated our Docker documentation to include this information about using a proxy with ProGet. I have also included more information about insecure registries and using self-signed certificates with Docker registries, Thanks, Rich

Not at present, but it's definitely on our roadmap, but there's not a ton of demand for it so we haven't prioritized it. The primary usecase seems to be having a Otter or BuildMaster server in the cloud that in-house servers connect to. Is that what you were thinking?

Hi @david-osborne_4674, Are you able to pull successfully using npm and ProGet? Also, does your API Key have the Feed API right enabled or if you are impersonating a user, does that user have the ability to publish packages? Also, when you set your NPM auth using: [~]$ npm config set always-auth=true [~]$ npm config set _auth={ENCODEDAPIKEY} Are you base64 encoding your API Key using the format api:{APIKEY}. For example: If my API key is FakeApiKey, I would want to base 64 encode api:FakeApiKey would be YXBpOkZha2VBcGlLZXk=. So the commands to run would be: [~]$ npm config set always-auth=true [~]$ npm config set _auth=YXBpOkZha2VBcGlLZXk= Alternatively, you could use npm adduser to login. Here are some examples: If you ran the command to make ProGet your default repo: npm adduser --always-auth If you are using multiple repos: npm adduser --registry=http://progetrepo/feedname --always-auth If you are using scoped repos: npm adduser --registry=http://progetrepo/feedname --scope=@inedo --always-auth This way uses a username and password. If you want to use an API key, use API as the username as the API Key as the password. Hope this helps! Thanks, Rich