Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

203
Views
Best practice regarding PackageReference version when publishing Nuget packages?

What is the best practice when specifying the PackageReference when publishing Nuget packages?

According to https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files, specifying the version number is equivalent to >= that version.

For example the following would reference version 11.0.1 or later of Newtonsoft.Json and 106.9.0 or later of RestSharp.

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="11.0.1" />
    <PackageReference Include="RestSharp" Version="106.9.0" />
  </ItemGroup>

If another developer wants to use my Nuget package in his project, that same developper may also need those same packages within his project and he may not be able to nor want to work with the same versions that I have been using. As such, what is the best practice? Should I always specify the lowest compatible version when I publish or do I just update my packages as I see fit for my project and not worry about the version numbers that get published?

over 4 years ago · Santiago Trujillo
2 answers
Answer question

0

Speaking from a consumer standpoint I'd say, yes, you should specify the lowest compatible version. That way, as you mention, you are not enforcing consumers of your package to have to upgrade e.g. their Newtonsoft.Json dependency if they happen to have a direct dependency to that package's version 11.0.0. If for some reason you won't allow version 11.0.0 to be used, then of course you should specify 11.0.1.

If, for example, you know Newtonsoft.Json version 11.0.1 has a critical security vulnerability, you may want to enforce a new version if it's been patched. But in general I think, as a package provider, you'd be interested in making your package as compatible as possible for the consumers' sake. Although, that doesn't mean you shouldn't keep the package up-to-date with its dependencies.

over 4 years ago · Santiago Trujillo Report

0

There is always a trade-off. Your library package reference version could become outdated for things outside your control. For example, if you have no new feature to release for your library but one of the dependent libraries is been updated, you may not want to update your Nuget. That said if there are some critical security updates that you would need to update your library.

Slightly, unrelated but one of the old recommendations from .NET Standard may come in handy for you to make your decision.

When choosing a .NET Standard version to target, consider this trade-off:

  • The higher the version, the more APIs are available to your library's code.
  • The lower the version, the more apps and libraries can use your library.

Personally, when working with Nuget packages, I try to use the latest of the dependent packages to ensure I can get the latest features without worrying about the security vulnerability.

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!