January 7, 2017

Continuous Integration and Deployment Basics for .NET Developers - Part 3

Dependency Resolution

The first thing to address is that you don't really want external dependencies stored in your source control system if you can help it. It's just extra clutter. Ideally, you just want your code in there where possible.

External dependencies are better satisfied at build time - especially if they can be obtained in some stable fashion from some other dependency management system such as NuGet. If you have external dependencies that aren't NuGet packages, the best options at this time appear to be:
  • Package them into a NuGet package and store them in a local instance of a NuGet server so that the build server can pull them down and include them in the build (more ideal).
  • Add them to a folder in your solution and store them in source control (less ideal).
There are scenarios where storing dependencies in source control make sense. These decisions should be considered carefully on a case by case basis.

I tend to prefer NuGet, or more specifically at this time I'm quite enjoying Inedo's ProGet. You can make your own choice, there are a number of ways of satisfying NuGet dependencies at build time. I like ProGet because its interface is simple, intuitive and allows me centralized management of multiple different types of feed all in once place and it ties into Active Directory nicely for authentication and authorization.

Presently the NuGet team has decreed that dependencies shall be satisfied outside of the compilation and should be handled by the NuGet.exe commandline tool. Prior to this, NuGet added build targets and binaries to a .nuget folder within your solution. Both approaches still currently work. Obviously having the targets and binaries in .nuget folders in your source control system means that every project you have in source control has these binaries and target files... so just clutter really.

I prefer to not add NuGet to my application stack and keep my codebase as pure as possible. I download the NuGet commandline tool to a folder on my build server and add the folder to my path to reference it. I can then handle dependency resolution for any project by running the commandline tool as a prebuild step. This means that my build server doesn't end up with 100 instances of the NuGet commandline tool floating around in various project directories, it doesn't end up checked into my source control system for every project that requires it and developers don't even need it on their machines because Visual Studio handles NuGet dependency resolution quite nicely. In my mind, this is the most efficient approach.
  • NuGet commandline tool: https://dist.nuget.org/index.html
  • Inedo ProGet: https://inedo.com/proget/download
This about covers dependecy resolution.

Continue to Part 4 - Versioning

No comments:

Post a Comment