There is a task attribute called "Delete Package". Just make sure you have a Task that has that attribute. You can see more info about it here: https://inedo.com/support/documentation/proget/administration/security/creating-tasks

Thanks. FYI: Retention policies should be ignored on free versions. But UNKNOWN does indicate the service user; so it's likely a retention policy job (which is run as part of feed cleanup). You can see the logs of those, and maybe see some more info...

I know you can delete all extensions, restart container, then re-download as needed. Its should help!

Thanks Alana, we will update our the inedo Core when the new version will be available.

We've included a fix for this in ProGet 5.1.0, which will likely be released tomorrow. Thanks!

I's possible the way permissions are validated in the installer is not applicable to RDS instances of SQL Server (I know a while ago there was a similar issue with Azure databases since the particular query we used to check was disallowed). Can you try pointing at a local SQL Server Express instance, then changing the connection string in the %PROGRAMDATA%\Inedo\SharedConfig\ProGet.config post-install (and then restart web service and ProGet service)?

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.