.NET / TFS - Source Control - Output of One Build Included In Another

Question

What is the proper way to include an output of one build as a binary in another build?

Lets say I have a solution called CompanyName.Domain (my Domain Layer). I have it set up as a build and it builds nightly.

Now I want to add a solution called SomeProject.Web. And I want to include the binary out of CompanyName.Domin into a Binaries folder at a peer level with my solution. Then the project SomeProjects.Web reference to Binaries\CompanyName.Domain.dll will work.

What is best practices for doing this? I know someone who said they were trying to do this with branching. I'm a total "source control" newb. But something about this sounds wrong.

Answer 1

My company does this by creating a "References" folder to hold all the .dll files necessary to build externally referenced assemblies, as the bin folder doesnt actually get saved under source control.

Answer 2

Just like Daryl, we use a "Binaries" folder that we reference binaries from. Our "libraries" builds just xcopy the results into the binaries location, so if we wish to update the libraries, we just check out the binaries, build, and check them in again.

This allows us to share all our internal libraries (as well as any 3rd party libraries we use) from a single standardised location, and all our libraries can be prebuilt, saving our devs having to build them if they are not actually changing anything in the libs .

Take care to only reference Release builds of your libraries (the only exception we have to this is that we have a library of debugging helpers which are conditionally compiled into debug builds only, and we must reference the debug version of it otherwise all our debug is compiled out of the program even in debug builds!)

One last note: Avoid branching unless there is no reasonable alternative.

Answer 3

We use the TFS Dependency Replicator, which can copy files to any project in TFS after a project builds. It doesn't have real great documentation, but it seems to do what it's supposed to after you get it setup.

The blog post Implementing Dependency Replication with TFS Team Build recommends setting up a branching scenario to aid with tracking which projects are using which dependencies, which makes sense to me, too.

Answer 4

My process is similar to that of the other posters.

Say I have two projects, call them CoreProject and AppProject. CoreProject is shared. AppProject has a folder called SharedBinaries. This is where all the assembly references point to.

My TFSBuild script for CoreProject is configured to do the following:

-Get Latest

-Build Drop to drop zone (something like \\SERVER\DropZone\CoreProjectBuildNameAndNumber)

-Drop is copied to a folder in the drop zone (something like \\SERVER\DropZone\Latest\CoreProject)

The TFSBuild script for AppProject is configured to do the following:

-Get Latest

-Check out files in the SharedBinaries folder

-Copy files from \\SERVER\DropZone\Latest\CoreProject

-Build

-Drop to drop zone (something like \\SERVER\DropZone\AppProjectBuildNameAndNumber)

-If the build is successful the build is copied to a folder drop zone (something like \\SERVER\DropZone\Latest\AppProject) and the files in SharedBinaries are checked in

-If the build fails the files copied into SharedBinaries have the checkout undone.

I've found this works out really well. AppProject is always building with the most current bits from CoreProject, so we know right away if there is a breaking change. By having SharedBinaries checked into TFS I can get a specific version and run the code with the same dlls from CoreProject that were used at that time. Also I just have to get latest and my local machine is building with the latest bits as well.

Answer 5

What if you have a Release and Debug build for the "CoreProject?" Let's say I have a DEVELOPMENT branch in my AppProject and in that DEVELOPMENT branch, I want to reference the Debug build of CoreProject?