Rules to Better Nuget
Since 1990, SSW has supported the developer community by publishing all our best practices and rules for everyone to see.
If you still need help, visit SSW Consulting Services and book in a consultant.
Reasons for avoiding checking Nuget or Npm packages
- Distributed version control systems, such as Git, include full copies of every version of every file within the repository. Binary files that are frequently updated lead to significant bloat and lengthens the time it takes to clone the repository.
- When packages are included in the repository, developers are liable to add references directly to package contents on disk rather than referencing packages through NuGet, which can lead to hard-coded path names in the project.
- Figure: Do not have a folder called "packages" or "Node_Modules"
Read more about how to omit NuGet packages in source control system
For better package management , may consider using the Package Management tool in TFS
Nuget is great for managing publicly available packages, but it’s also surprisingly easy to create and publish your own packages to your own nuget server for internal code reuse across multiple solutions.
- Figure: You can create your own nuget server by simply creating a new asp.net web project and adding the Nuget.Server package
- Figure: Add your new server as a package source under Tools | Options | Nuget Package Manager | Package Sources
Nuget makes it easy to find and apply package updates – but this still must be performed manually.
Each package update should contain improvements but also involves a small amount of risk in the form of breaking changes or regressions.
Updating often can help mitigate this risk by ensuring that each individual update is smaller.
Recommended practice is to apply package updates at the start of a sprint so that there is time to find and resolve issues introduced by the update.
- Figure: Nuget package updates