Question

我有一个包含多个项目的解决方案，其中一个项目是所有其他项目所必需的

我的目录如下所示：

|-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
|

我为MyProduct.Web，MyProduct.Api等提供了TeamCity构建....

我遇到的问题是所有3个都依赖于MyProduct.Core 当解决方案签入源代码控制（git）时，TeamCity构建项目，但显然它无法在MyProduct.Core依赖项上进行编译，因为它不存在。每个构建版本仅包含MyProduct.Admin（例如）

的内容

如何让它与Teamcity合作？

nb - MyProduct.sln是一个“整体”解决方案。每个域都有自己的解决方案（因为每个项目通常包含多个csproj）

Answer 1

您可以在同一目录中引入核心项目，首先构建它，然后构建另一个项目。

实际上：假设您有一个VCS根MyProduct.Core而另一个MyProduct.Admin，将两个根连接到构建配置并编辑每个根的结帐规则：首先将其设置为{{ 1}}，第二个到+.:=>MyProduct.Core。在chekout之后，构建目录包含您在问题中显示的确切结构，当然减去主要的sln文件。现在为构建核心添加构建步骤，为管理员添加另一个构建步骤。请注意，如果您需要访问.git功能以获取SHA等等，则必须使用“Checkout on Agent”。

也许有可能使用工件，但我个人更喜欢上面因为你完全确定所有东西都得到了正确的重建，而且它类似于我在自己的开发机器上所做的事情。

Answer 2

要考虑的另一个选择：构建Core并在本地将其作为NuGet包发布（TeamCity可以充当NuGet server）。在其他项目中，引用此NuGet组件。

我建议更多内部库组件，而不是Core项目 - 假设Core可能需要频繁编辑。在那种情况下，请选择Paul的答案：Artifact Dependencies。

Answer 3

您可以使用Artifact Dependencies

一个构建的工件（.dll）用于另一个构建。

或者，如果您使用的是Git，请使用子模块。

TeamCity构建 - 跨其他构建共享核心项目

3 个答案: