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.

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