Build Process Design: Nuget vs Artifact Dependencies

Question

I have an application A that depends on an internal shared library B. A and B each has their own repositories.

I'm using TeamCity 10 to build these two projects. Two ways I considering doing this:

1. Build B and publish the dlls as artifacts. Build A with an artifact dependency on B.

2. Build B and publish as a nuget package. Build A with a nuget dependency on B.

My questions are:

1. Which approach is better?

   • Artifact dependencies seem like the simplest approach and can get the job done, but if we go the nuget route, we can generalize dependency resolution and decouple it from the buildserver to do it. Another advantage I can see with nugets is that when developers checkout solution for B, any dependencies can be resolved through nuget. While for artifact dependencies, some type of pre-build script on the developer's local machine is needed to retrieve/copy dll artifacts, mimicking what TeamCity does with artifact dependencies on the buildserver (is there a better approach for this?).

2. If we implement nuget dependencies, why would we ever need artifact dependencies at all?

Thanks in advance for any feedback offered.

Answer 1

The best approach for this is based on your projects developing progress.

If the project A and Project B are still in developing, I suggest you use artifact dependencies. Since you will change the projects very often when developing them, in TeamCity you just need to add artifact dependencies to the build configurations. No matter how you change the projects code, the build configurations need not to change.

If the projects development has finished, the NuGet dependencies is a good choice. Because if you are using NuGet dependencies when developing the projects, when any code changed during developing, you need to re-pack the packages and reinstall it into your project.