Ask A Question

View Question

Recently went from 3.8.1 to 4.8.2 and now have better connector functionality, thank you. However, we are seeing the pre-release packages show up in feeds with a nuget v2 connector. How can we filter those out? Specifically when we view a package with dependencies if the dependency has a prerelease package, that's the one we end up seeing and linking to in the web UI.

An example:
Serilog.Sinks.File v3.2.0 requires Serilog (>= 2.3.0)
Serilog's latest published version is 2.5.1-dev-00890 (which we don't want to see in ProGet).
Serilog's latest non pre-release/stable version is 2.5.0 (which IS the one we want to see in ProGet).

An alternative behavior would be that the pre-release ones show up but everything would default to using stable/non-pre-release packages unless specifically called out to include them by the user. Same as on nuget.org.

Product: ProGet
Version: 4.8.2

Due to technology/querying limitations of NuGet.org, we are quite limited as to what filtering options we can do. This is why many of the filters (vulnerability, licensing, etc), are simply blocked from being downloaded (but still appear in a query).

If establishing an internal policy doesn't work, you could certainly write a package access rule using the SDK (see the whitesource extension as an example), to prevent these from being consumed.

I will definitely look into the extension documentation. Thank you for mentioning it.

But, you're saying this won't work?

https://www.nuget.org/api/v2/Packages()?$filter=IsPrerelease%20eq%20true&$top=10

I imagine I'm misunderstanding something you said, or there maybe something else I'm not aware of when querying nuget.org.

It certainly might... but we haven't evaluated it for performance considerations, etc. Early on, we tried implementing a much more advanced filtering system (author, versions, etc), but it really put a strain on NuGet.org and became useless, so we didn't continue on that featureset.

This is the first request for this specific filter, and it might be simple, but we'll definitely consider it.

Answer Question