Usually no. VersionOverride lets one project ignore the version in Directory.Packages.props, which undermines the point of central control. Set CentralPackageVersionOverrideEnabled to false so any override fails at restore, and allow exceptions deliberately, each with a named reviewer and a written reason.
What the feature does
With central package management, versions live in Directory.Packages.props and project files list packages without versions. A project can still write a VersionOverride on a PackageReference, and that value takes precedence over the central PackageVersion entry.
<ItemGroup>
<PackageReference Include="PackageA" VersionOverride="3.0.0" />
</ItemGroup>
It is meant for rare cases, such as one project that cannot move to the shared version yet.
The security case against open overrides
- A vulnerable version can stay in one project while the central file shows a fixed one.
- Reviewers who read only Directory.Packages.props see a clean list.
- Audit warnings will still fire, but a scattered override is easy to miss in a large diff.
- Over time, overrides accumulate and nobody remembers why.
How to switch it off
Microsoft documents a property for this. Set it in Directory.Packages.props, Directory.Build.props, or a project.
<PropertyGroup>
<CentralPackageVersionOverrideEnabled>false</CentralPackageVersionOverrideEnabled>
</PropertyGroup>
When it is false, a VersionOverride on any PackageReference produces an error at restore time saying the feature is disabled.
Options when you genuinely need a different version
| Situation | Approach |
|---|---|
| One framework needs an older package | Use a Condition on PackageVersion by target framework |
| One legacy project is stuck | Enable override only for that project, with a comment and an owner |
| A library needs a lower floor | Keep versions central, and review pack output |
| Temporary security fix | Pin centrally rather than overriding per project |
Per target framework versions are described in the same Microsoft page, using MSBuild conditions on PackageVersion items.
A short policy you can adopt
- Disable overrides at the repository root.
- Re-enable in a single project only through a pull request that names the reason.
- Add an expiry note, such as a date or a ticket number.
- Search for VersionOverride in CI and print a count, so growth is visible.
- Review the list each quarter and delete what is no longer needed.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a rule blocks a change before it merges, which is the same idea as failing restore on an override.
Safeguard policies and gates can block a pull request that introduces a vulnerable dependency, and a free scan shows your current state.
Quick check
Does VersionOverride change the version in Directory.Packages.props?
No. It overrides it for one PackageReference in one project, which is why it is easy to miss.
What error appears if overrides are disabled and someone uses one?
Restore fails with an error stating that the feature is disabled.
Sources
Last reviewed: 19 October 2026.
