<![CDATA[Noncompliant packages can still be downloaded]]>I’ve spent some time configuring licenses in ProGet and expected them to prevent certain packages from being consumed, but I’m seeing inconsistent behaviour.
For example, I created a custom license rule covering FluentAssertions versions 8.0 and above, and marked them as noncompliant. This appears to work correctly in the ProGet UI. Those versions cannot be downloaded.
However, this restriction does not seem to apply when installing packages via Visual Studio or the NuGet CLI. I’m still able to install those same versions without any issue.
To rule out external sources:

I’ve disabled all package sources in Visual Studio except our ProGet instance
I’ve explicitly specified the ProGet feed URL when installing from the command line

So I don’t believe the packages are being pulled from elsewhere.

Expected behaviour:
Marking a package/version as noncompliant should prevent it from being installed via the feed.

Actual behaviour:
The restriction is only enforced in the UI; installs via NuGet/Visual Studio are unaffected.

Is this the intended behaviour? If so, what is the purpose of marking packages as noncompliant?
If not, is there an additional setting or configuration required to enforce this at the feed level?

Web UI Version: 2025.20 (Build 23)
Database Schema Version: 25.0.20.23

]]>https://forums.inedo.com/topic/5735/noncompliant-packages-can-still-be-downloadedRSS for NodeThu, 30 Apr 2026 12:13:38 GMTWed, 29 Apr 2026 10:28:26 GMT60<![CDATA[Reply to Noncompliant packages can still be downloaded on Wed, 29 Apr 2026 10:28:26 GMT]]>I’ve spent some time configuring licenses in ProGet and expected them to prevent certain packages from being consumed, but I’m seeing inconsistent behaviour.
For example, I created a custom license rule covering FluentAssertions versions 8.0 and above, and marked them as noncompliant. This appears to work correctly in the ProGet UI. Those versions cannot be downloaded.
However, this restriction does not seem to apply when installing packages via Visual Studio or the NuGet CLI. I’m still able to install those same versions without any issue.
To rule out external sources:

I’ve disabled all package sources in Visual Studio except our ProGet instance
I’ve explicitly specified the ProGet feed URL when installing from the command line

So I don’t believe the packages are being pulled from elsewhere.

Expected behaviour:
Marking a package/version as noncompliant should prevent it from being installed via the feed.

Actual behaviour:
The restriction is only enforced in the UI; installs via NuGet/Visual Studio are unaffected.

Is this the intended behaviour? If so, what is the purpose of marking packages as noncompliant?
If not, is there an additional setting or configuration required to enforce this at the feed level?

Web UI Version: 2025.20 (Build 23)
Database Schema Version: 25.0.20.23

]]>https://forums.inedo.com/post/19608https://forums.inedo.com/post/19608Wed, 29 Apr 2026 10:28:26 GMT<![CDATA[Reply to Noncompliant packages can still be downloaded on Wed, 29 Apr 2026 11:25:04 GMT]]>Hi @daniel-mccoy_4395,

Based on what you've described, it sounds like ProGet is indeed blocking downloads; this is visible in the ProGet Web UI with a "Download Blocked" indicator. If you try accessing the download URL, you will in fact get a 400 error.

However, NuGet/Visual Studio aggressively cache package - which means they aren't even attempting to download them. If you clear all the NuGet caches (system, user, http, project, etc), then it should attempt to download then again.

That said, as of ProGet 2026, we no longer recommend downloads. This is one reason, but there are more reasons.

Here's an work-in-progress article that discusses our new guidance:
https://guides.inedo.com/vulnerability-management/containment/

Cheers,
Alana

]]>https://forums.inedo.com/post/19609https://forums.inedo.com/post/19609Wed, 29 Apr 2026 11:25:04 GMT<![CDATA[Reply to Noncompliant packages can still be downloaded on Wed, 29 Apr 2026 12:12:45 GMT]]>Yes, you're right.
I cleared the cache with nuget locals all -clear, after which I could no longer install the same package via Visual Studio or the command line.

Thank you for pointing this out to me.

]]>https://forums.inedo.com/post/19610https://forums.inedo.com/post/19610Wed, 29 Apr 2026 12:12:45 GMT