Hello Lev, A possible reason this might be happening is if Apache is caching the 404 error returned by Docker when the client checks for an existing layer and then returning the cached error after the layer is uploaded and the blob URL becomes valid.

I see; my guess is that they have a custom-developed feed, and that feed is only supporting the limited/minimum number of queries required to get it working in the versions of Visual Studio of they support. In other words, it's not a proper feed. ProGet relies on a feed implementing the required API endpoints. In this case, your best bet will be to download the packages from the vendor, and then upload them into your ProGet repository.

It's obscured from view in the UI, but we must store the password so that it can be used for authentication. We may support a encrypted credential in the future, but if you have access to the ProGet server you will always be able to decrypt it.

Hello Chris, I don't think Bower feeds store anything on the filesystem (it's all in the database). I've filed PG-1256 to add support for Maven feeds being stored in package stores.

Hi, I'm afraid we don't have a step-by-step tutorial available at this time. It's enough of a challenge to always keep our tutorial screenshots up-to-date, let alone screenshots of Amazon's interface :( But if you get stuck, please let us know. It should be pretty straightfowrard and similar to a regular installation on a virutal machine,.

Haha, I missed it by one minor verison. :-D Sounds good. Thanks for the quick response. Means I get to test my scripted upgrade process. :-D Have a good one.

That's actually pretty awesome. that's exactly what I was sort of thinking of doing.

Thanks for letting us know. We are totally redoing our installer soon, so we will probably take care of it then! I think, generally, you might want to install SQL separately when going automated. When SQL fails to install, it's not so graceful, and it will be harder to tell what went wrong when diagnosing a failed ProGet installation

This is not supported at this time.

No special case. The link to the package statistic indicate 863 downloads and when we click on this link it show us only local package and note what is present in the cache. It's just disturbing. And the statitc on remote package are instrusting as local packages.

Somewhat similar to the post you've read already, but I've provided an answer to this kind of problem before: https://inedo.com/support/questions/7990 Basically it's setting up two IIS sites, one with Windows auth the other with Basic Auth (or anonymous if you want). One instance of ProGet, but two ways to get to it. We've been successfully using ProGet with both Windows Auth (for .NET nugets) and Basic Auth (for npm and docker) for about a year now, with the configuration described in the post I referenced. David

Hello Dmytro, I've filed PG-1252 to address this.

Once I flushed the browser cache, everything rendered as it should.

I'm not sure why, but looking at .11 and .12, they would only impact Windows installations, so you can just use .10 or upgrade to v5.

It was generalized to use ProGet's API keys which have more granular security options: https://inedo.com/support/documentation/proget/feeds/nuget#nuget-api-key

I'm not too familiar with how OneGet fits into all this; you'd really be better asking this question at the Chocolatey or OneGet forum. You'll still use ProGet to host the packages, but I'm really not sure which client tool (choco, etc) will do the download and install on a desktop.

Hi Ben, Yeah adding a licence fixed this problem. Thanks for the hint. Have a nice day.

Hello Subash, To check whether any connectors are unhealthy, you could use a PowerShell script like this: $someConnectorsUnhealthy = ( Invoke-RestMethod 'https://devget.syhapp.com:8798/api/json/Connectors_GetConnectors?API_Key=*******&Feed_Id=***' | Where-Object { $_.Status_Code -ne 'H' }).Count -gt 0 After this, $someConnectorsUnhealthy is $True if any connectors for that feed are not in a healthy state, and $False if all connectors are healthy. If your API key contains = or +, it needs to be URL-encoded, with = replaced by %3D and + replaced by %2B. Alternatively, you can change the API key to be URL-safe.

The error is "failed with: 401 Unauthorized", so it probably means you need to specify an authentication source? We didn't change the way authentication is handled in v5, so it's likely unrelated to the upgrade.

Hi Ben. Thank you for the clarification of the problem scope. Look forward to the fix. Thank you for the quick response, much appreciated +1 Inedo has excellent support and reacts promptly.