I have a solution with several projects, one of which is required by all other projects
My directory looks like this:
|-MyProduct.Web
| |-MyProduct.Web.Project1
| |-MyProduct.Web.Project2
| |-MyProduct.Web.Project3
| |-MyProduct.Web.sln
|
`-MyProduct.Api
| |-MyProduct.Api.Project1
| |-MyProduct.Api.Project2
| |-MyProduct.Api.sln
|
`-MyProduct.Admin
| |-MyProduct.Admin.Project1
| |-MyProduct.Admin.sln
|
`-MyProduct.Core
| |-MyProduct.Core.Project1
| |-MyProduct.Core.Project2
| |-MyProduct.Core.Project3
| |-MyProduct.Core.Project4
| |-MyProduct.Core.Project5
| |-MyProduct.Core.sln
|
|-MyProduct.sln
|
I have TeamCity builds for MyProduct.Web, MyProduct.Api etc....
The problem I'm having is that all 3 have a dependency on MyProduct.Core
When the solution is checked in to source control (git) TeamCity builds the projects, but obviously it fails compilation on the MyProduct.Core dependency, because it is not there.
Each of the builds only has the contents of MyProduct.Admin (for example)
How can I get this to work with Teamcity?
nb - MyProduct.sln is an 'overall' solution.
Each of the domains has it's own solution also (as each project usually contains multiple csproj)
You could pull in the core project as well in the same directory, build it first, then build the other project.
In practice: suppose you have a VCS root MyProduct.Core and another one MyProduct.Admin, attach both roots to the build config and edit the checkout rules for each: for the first you set it to +.:=>MyProduct.Core , for the second to +.:=>MyProduct.Admin. After chekout the build directory contains the exact structure as you show in your question, minus the main sln file of course. Now add a build step for building core, and the other one for admin. Note if you need access to .git features to get the SHA and whatnot, you must use 'Checkout on Agent'.
It might also be possible using artifacts, but personally I prefer the above because then you're absolutely sure everything got rebuilt properly, plus it resembles what I'm doing on my own development machine.
Another option to consider: build the Core and publish it locally as a NuGet package (TeamCity can act as a NuGet server). In the other projects, reference this NuGet component.
I'd recommend this more for internal library components, rather than a Core project - assuming that the Core may require frequent edits. In that situation, go with Paul's answer: Artifact Dependencies.
You could use Artifact Dependencies
One build's artifacts (.dlls) are used for another build.
Or, if you are using Git, use submodules.
