Loading page
About this tool
Build PackageReference items with version ranges, asset flags and Central Package Management, and see what each range really allows.
This builder writes the PackageReference items a .NET project file uses to declare NuGet dependencies, and translates each version range into the interval it really matches. NuGet's interval notation is easy to misread: 1.0 is a minimum, [1.0] is exact, [1.0,2.0) means at least 1.0 and below 2.0, and a square bracket is inclusive while a round bracket is exclusive. It also emits a Directory.Packages.props file when you switch on Central Package Management.
Open NuGet Package Reference Builder on AltFTool — it loads instantly in your browser.
Provide your input — an image, text, or data.
Let the tool analyze or generate the result.
Review, refine, and reuse the output wherever you need it.
Every bracketed range is restated as a plain >= and < interval.
Catches (,), a lower bound above the upper bound, and ranges that can never match.
Only real NuGet asset groups are accepted, and all cannot be mixed with others.
1.0 is a minimum version — NuGet may resolve 1.0 or anything higher — whereas [1.0] pins the reference to exactly 1.0 and restore fails if that version is unavailable. Square brackets are inclusive bounds and round brackets are exclusive, so [1.0,2.0) means at least 1.0 and strictly below 2.0.
It stops the dependency flowing to projects and packages that consume yours: the reference is used while you build, but it is not written into your package's dependency list. It is the standard setting for analyzers, source generators and build-only tooling such as StyleCop.Analyzers.
Set ManagePackageVersionsCentrally to true in a Directory.Packages.props file at the repository root, declare each version once with a PackageVersion item, and remove the Version attribute from every PackageReference. Every project below that directory then resolves the same version, and floating versions are not allowed.
Only when you actively want the newest patch on every restore, and only with a committed lock file, because otherwise two machines can resolve different versions from the same source. For reproducible CI builds pin an explicit version or a bounded range instead.