1

I have two separate solutions in TFS 2015. We'll call them Solution1 and Solution2. The build for Solution1 creates an assembly which is required by Solution2. I'm not sure of the best way to handle this dependency in TFS.

Possible scenarios could include.

  • Each time Solution1 builds successfully it copies the new assembly to Solution2 which in turn triggers a build of Solution2 (is this possible in TFS? And if so, how?)
  • Each build of Solutiuon2 pulls the latest version of the assembly from Solution1

How have other people handled dependencies between TFS projects?

DomBurf
  • 2,452
  • 5
  • 36
  • 71
  • Private Nuget repository? Deploy step which copies to known location, and pre-build step which retrieves it? – Ben Feb 21 '17 at 10:48
  • @Ben There doesn't seem to be any way to chain builds together in TFS so I'm going add a pre-build step like you mentioned which retrieves the assembly. – DomBurf Feb 21 '17 at 12:02

2 Answers2

4

You should package the output of Solution 1 as a Nuget package and publish it to a Nuget repository. You can use a Network Share, MyGet, VSTS, or TFS 2017 as a Package Repo.

Your second solution can then take a dependantsy on that Nuget Package and you choose when to update.

If you want to update the packages automatically you can call something prior to Solution 2 build, like the pre-build step mentioned in comments.

MrHinsh - Martin Hinshelwood
  • 23,409
  • 5
  • 46
  • 69
0

As it was explained in the other answer you can manage it with NuGet deployment. That is the really clear and fancy way.

Another way might be, if you use the same output folder for both solutions, and you always build Solution1 first.

The third way can be that you always deploy your Solution1 to a specific location which can be referenced by Solution2. It is logically similar to the NuGet version, however you do not rely on that (but this dependency in "normal" cases is IMHO acceptable).

Your actual choose can depend on the environment and on your constraints.

eldor
  • 151
  • 5