It's fixed. Not only that, but listing the packages also seems faster. Thanks!

This is actually an artifact of the OData specification from when ProGet was first developed - that was actually the preferred format specified, and NuGet.org didn't support $format=json, so we just followed the OData spec. Anyway, those are just .NET DateTime Ticks in there (and the +0 just indicates UTC), so in your example it would just be: new DateTime(636650168208570000, DateTimeKind.Utc) Of course, if we had it to do over again, it would be something more sensible like ISO-8601.

Hello William, This will be fixed in ProGet 5.1.2. (PG-1294)

Understood, thanks for the explanation! So this is an issue on the Jetbrains end. We will definitely contact them and see the course of action that's available. Thanks again!

This will be addressed in next maintenance release as PG-1294 . As a workaround, you can access the package directly by version number even without this fix.

I can't seem to find any indication that endpoint is part of official NuGet API, but in ProGet if you want a specific file you can query as per this example: http://proget.company.com/package-files/download?packageId={packageId}&version={packageVersion}&feedName={feedName}&path={packageId}.nuspec A live example: https://proget.inedo.com/package-files/download?packageId=InedoLib&version=528.0.0&feedName=ExternalBuild&path=InedoLib.nuspec

Use permissions for this. There is a Feeds_OverwritePackage task or something that you can remove, or restrict as you see fit.

I had to update the NuGet feeds to the latest version after the upgrade. The packages are pulling in now.

Hello Attila, This is indeed a bug. I've filed PG-1272 to fix this.

I can answer the first three questions pretty easily: ProGet does not support being installed as a sub-application; some users have done a reverse proxy successfully, but we really don't support that configuration The Feed url is based on the name of your feed, so it can be whatever you want. You can't do further customization. That's not a problem But I'm afraid I really don't understand the situation about 4-6. ProGet does have some extensibility hooks that you may be able to use.

unfortunately this bug fix just missed the cut. But we will ship it in the next maintenance release, likely in a couple weeks. It's not scheduled yet.

This particular error (the 500) will be fixed with PG-1313

I'm afraid Linux doesn't support Windows Integrated Authentication. As a work-around, you can create a second site in IIS that points to the same path, but doesn't have Windows Integrated Authentication enabled.

Hi @ReginaldD, did you manage to bulk-delete packages from your server using inedo API? Cheers,

You'll want to push a "combined" symbols package to http://🚫/nuget/feed-name - the symbols endpoint is for downloading extracted symbols only. Check out the guide we have at Symbol and Source Server docs for more info

To resolve this issue, I disabled Anonymous Authentication for the ProGet website in IIS (leaving just Windows Authentication enabled) and restarted all services. I tried this previously to no avail but for some reason it is working fine now.

yes, after subscribing to one of our vulnerability providers like Sona OSSIndex or Whitesource (more coming later).

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.

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

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