Yes, it just involves changing the license key. Please refer to License Key Management

Hi Tod, Thanks for looking into this. I just checked and can confirm that the last time we received this error it matched up with an app pool recycle. I'm not sure yet whether this is the source of all our timeouts, but that's certainly given us something to work with. I'll post again if we suspect any other Proget related issues. Thanks again.

We can't reproduce this - in all cases we've tried the casing of supplied package ID's does not matter in requests to ProGet. If you capture the failing requests using Fiddler and attach them to a ticket, we can hopefully find out why it is not working for you.

I think that guide is more for when you host a domain controller in azure as IaaS. Im after connecting to Azure AD in the form of SAML, or OpenIDConnect (Federation) I'll keep an eye on release notes to see when SSO gets released. Thanks

Thanks Greg, That cleared it all up for me.

I'm directly executing the DashboardFeeds view, so I'm not using the parameter. It seems that the SUM([Package_Size] for [Feed_Size] and [Cache_Size] are the culprit. When I replace the query with [Feed_Size] = 0, [Cache_Size] = 0 then the timeouts are gone! They are just missing from the feed disk usage graph. Adding an index to NuGetPackageVersionsV2.Package_Size didn't help. The strange thing is that some pages that are not using the graph are also executing the DashboardInfo stored procedure.

Just to be clear... you can't go from Windows >> Linux, because it's PostgreSQL vs SQL SErver. But if you're already on Linux edition, you can just upgrade the container; the database files and package stores are already configured to point outside the container.

You can request a free key at https://my.inedo.com/

We believe we have fixed this as PG-1377, which will be included in ProGet 5.1.11. Thank you!

I'm afraid I don't really understand the requirements for what you're trying to accomplish... Here are the differences between the two extensibility points: A Package Filter allows all locally-stored ProGet packages to be filtered from being shown in feeds by additional logic. A Package Access Rule Allows for rules to block downloads of packages based on additional logic. The Package Access Rule is used by the Whitesource extension, so you can reference how that works. We don't have any publicly available uses of Package Filters; it was incorporated for a very specific usecase with publicly-available feeds.

It is a working feature, but there are some known issues (PG-1343 and PG-1344) that we will have fixed soon. You can find the documentation here.

Hello, Just following up: The root cause of Windows images from connectors not working is that ProGet was not telling the connector that it supported v2 manifests, and the v1 manifests generated for Windows images by Docker Hub are broken. This is PG-1351.

The tracking issue for this is here: PG-1337

Of course, modifying a package file (i.e. stripping symbols/source) will cause the hash code to change, which is what the integrity check uses. There's no way around that. The stripping feature is important, because Visual Studio will not use a symbol or source server if the package has embedded symbols in it. You aren't supposed to put these in a nuget.org package, but some people clearly do (as the example above). So, just pick which is more important to you.

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

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.

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).

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

The problem was solved when remove dash from package name.