Behind the scenes, that's the only difference in how they're stored (and has been for as long as I remember); but I do know that data directly in the database is not officially supported. But for a one-off thing it's fine to do IMO

Did you reset to the Built-In authentification options ? If so you can use the default Admin account with the Admin password. You can also browse the database, find the account value and add your user directly in the table.

Soon --- this is a known issue, but we are in the process of resolving it; please see InedoCore#96

Hello Antoine and Anton, I've filed this as PG-1376.

Hello Florian and Antoine, I've filed this as PG-1376.

The problem was our proxy. npm doesn't use the proxy exceptions that are configured in the system, so after updating them to include the ProGet server domain it works as expected.

Yes, that would fix the installer issue and we do recommend moving to SQL Server 2016. The bundled SQL 2005 instance in the old installer was intended more for quick setup for evaluation purposes rather than production use, but we did a very poor job of making that clear. We are fixing that now; we're working on updating all of our installers to detect the SQL Server version and suggest/require an upgrade. Here is the current article about SQL Server requirements - basically it's any version currently supported by Microsoft. Sorry for the confusion, and hope this helps!

Currently assets do not have any user-definable metadata like this, I guess because that would make them a lot like packages? Assets also aren't intended to be like a "SharePoint replacement", which is why we don't want to put a lot of extra features like versioning, etc. These are also hard to replicate, etc. That being said, we are open to changes, so please consider using the Feature Request Process. Note that, we also want to evaluate "why" and "how this would be used", and that's part of the feature/change process.

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.