具有多个Visual Studio解决方案的TFS项目

Question

具有多个Visual Studio解决方案的TFS项目

29

我们的团队正在考虑使用 Team Foundation Server v.11（2012 年版）来管理我们的项目。我们目前是在电子表格中进行项目管理。我们的团队仅为内部客户开发软件，并且在项目之间存在许多 dll 共享。我们还在使用 SVN 进行源代码版本控制。

我们针对不同应用程序部分有不同的解决方案：通用库、应用程序库（业务规则等）、Intranet 网站、Internet 网站、Windows Forms。以下是我们的 SVN 结构。

SVN
    -CommonLibrary (VS Solution)
        -Source
            -CommonLibrary.Core (VS Project)
            -CommonLibrary.Security (VS Project)
            -CommonLibrary.Web (VS Project)
    -OurCompanyLibrary (VS Solution)
        -Libraries (Projects within this solution reference these)
            -CommonLibrary.Core.dll
            -CommonLibrary.Security.dll
        -Source
            -OurCompanyLibrary.Application1 (VS Project)
            -...
            -OurCompanyLibrary.ApplicationN (VS Project)
    -OurCompanyIntranet (VS Solution) (MVC framework)
        -Libraries (Projects within this solution reference these)
            -CommonLibrary.Core.dll
            -CommonLibrary.Security.dll
            -CommonLibrary.Web.dll
            -OurCompanyLibrary.Application1.dll
        -Source
            -OurCompanyIntranet.Application1 (VS Class Library Project)
            -...
            -OurCompanyIntranet.ApplicationN (VS Class Library Project)
            OurCompanyIntranet.UI (VS Web Project)
    -OurCompanyInternet (VS Solution) (MVC framework)
        -Libraries (Projects within this solution reference these)
            -CommonLibrary.Core.dll
            -CommonLibrary.Security.dll
            -CommonLibrary.Web.dll
            -OurCompanyLibrary.Application1.dll
        -Source
            -OurCompanyInternet.Application1 (VS Class Library Project)
            -...
            -OurCompanyInternet.ApplicationN (VS Class Library Project)
            -OurCompanyInternet.UI (VS Web Project)

将代码拆分为多个解决方案的原因是我们可以在不同的情况下重用应用程序库（Intranet应用程序、Internet应用程序、Winform应用程序）。此外，内部网和互联网解决方案包含多个应用程序。这是我们目前的结构。我不确定这是否是最佳的组织结构，但它对我们有用。使用TFS的问题在于一个团队项目无法在多个VS解决方案中具有部分。例如，我们将为Application1设置一个TFS团队项目，以便我们可以为该应用程序设立产品积压清单。 Application1需要更改OurCompanyLibrary、OurCompanyIntranet和OurCompanyInternet才能完成应用程序，但是，在使用TFS时，只会有一个VS解决方案用于Application1。以下是我们开发应用程序的示例。所有领域模型和业务规则都存储在OurCompanyLibrary VS解决方案中。当我们开发一个名为Application1的应用程序时，我们首先在OurCompanyLibrary VS解决方案下的OurCompanyLibrary.Application1 VS项目中创建领域模型和业务规则。一旦开发出领域模型，我们就会转向在OurCompanyIntranet和OurCompanyInternet VS解决方案中编写UI界面的程序。这些解决方案都是MVC样式的网站。 OurCompanyIntranet包含一个VS Web Project OurCompanyIntranet.UI，其中包含所有的视图（.aspx文件）、css、javascript等。OurCompanyIntranet还包含按应用程序分隔的所有模型和控制器（在这种情况下为OurCompanyIntranet.Application1）。将其组织到TFS中成为问题，因为我们想为Application1创建一个团队项目，但该应用程序可以跨越多个解决方案，并且我们不希望通过向源代码控制添加相同的OurCompanyIntranet和OurCompanyInternet VS解决方案来使每个地方都存在重复代码。您将如何在TFS中组织这一点？是否有其他方式可以组织我们的代码结构，这将更有意义？任何文章或网站都会对我们有很大帮助。

- awilinsk

4个回答

0

正如您所预测的：

OurCompanyLibrary将是一个VS解决方案。

OurCompanyLibrary.Application1 ... OurCompanyLibrary.ApplicationN将是该解决方案中的VS项目。

OurCompanyLibrary.ApplicationX.dlls将是OurCompanyIntranet和OurCompanyInternet VS解决方案中的引用。

我不确定我是否理解了您的问题。

在OurCompanyLibrary中的应用程序VS项目可以单独构建，生成自己的dll，然后可以在其他两个解决方案中进行引用。如果问题是所有应用程序都在一个VS团队项目（OurCompanyLibrary）下，则答案是为每个应用程序创建单独的VS团队项目 - OurCompanyLibrary1用于Application1，OurCompanyLibrary2用于Application2等。每个应用程序的开发完全独立且分离。

如果问题是您想要在不同的解决方案中使用不同部分的源代码，则可以通过将项目添加到解决方案来实现。但这意味着所有这些解决方案都拥有全部的源代码。我们在工作中有类似的情况：- 我们有一个包含2个项目的解决方案 - 我们的通用业务逻辑层和通用数据访问层。我们的其他解决方案都包含这些项目。这意味着我们可以从任何解决方案编辑源代码。

我不知道这些是否对你有帮助，但祝你好运！

- Paul C. Shirley

非常感谢您的回复。我们遇到的问题是一个应用程序（它将成为自己的团队项目）跨越多个VS解决方案，这些VS解决方案必须添加到每个团队项目中。OurCompanyIntranet解决方案针对每个应用程序和一个视图（MVC样式网站）具有VS项目。OurCompanyInternet.UI项目是一个网站项目，引用解决方案中的每个应用程序项目（OurCompanyIntranet.Appliation1 ... OurCompanyIntranet.ApplicationN）。我们希望将我们的解决方案结构与TFS相匹配。 - awilinsk

我编辑了我的原始问题，添加了一个我们如何开发应用程序的示例。我理解您的意思，将其他解决方案中的项目添加到团队项目的解决方案中。但是，在源代码控制中，我们如何避免重复？此外，我们如何为Application1团队项目创建构建，或者我们是否会在OurCompanyInternet和OurCompanyIntranet团队项目上创建构建？ - awilinsk

0

如果这是一个正在生产中运行的应用程序，我会尽量减少对文件夹/解决方案结构的更改。在TFS中，您可以在构建定义中选择多个项目，也可以像下面的示例一样将多个解决方案放入构建脚本中

如何从单个TFS团队构建定义构建2个解决方案

- bkraider

建设并不是我唯一关心的事情。我还希望能够只有一个跨越多个解决方案的团队项目，这样我就可以将该项目的所有内容都放在一个地方。 - awilinsk

0

如果你想对整个代码库进行集中报告，你应该探索使用一个 TeamProject 来托管所有东西的可能性。
然后，为了区分不同的组件/部分，可以在此 TeamProject 中使用单独的区域。
看看this非常有趣的文章，特别是 Pros/Cons 部分。

- pantelif

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Nock · Accepted Answer

首先，不要使用多个团队项目，这是每个人在开始时都会犯的巨大错误。对于您的团队规模和开发内容：一个团队项目就足够了。

只有当有两个完全不同的团队、在完全不同的项目上工作并使用完全不同的方法/流程时，您才需要使用两个团队项目。

有了一个团队项目，您仍然可以：

拥有许多分支（相关或不相关）。
以最小的级别管理源代码控制。
使用工作项的区域路径（节点树）将项目分成子类别（功能、技术或其他所需）。这样，您就可以拥有一个大型产品积压还是专门的积压。
整个项目或特定区域的总体报告（仍然使用区域路径，但在报告服务中）
相信我，这是最好的方法，很多人（包括我第一次）犯了使用多个团队项目的错误，此后不得不付出代价。您所需要的是一个好的源代码控制层次结构和一个好的区域路径树。

关于解决方案：

每个主要组件都有一个解决方案并不是一件坏事，开发人员可以在专用的项目子集上工作，以最大化生产力并减少组件之间的耦合。

但是，您仍然可以拥有一个全局解决方案，引用所有项目，并且每当您需要进行影响所有项目的更改时使用。拥有全局解决方案还是构建整个项目的简便方法。

问题在于跨组件引用，如果您开发的一个组件（例如Application1）需要另一个组件（例如OurCompanyLibrary），则会创建两者之间的依赖关系，并且Application1必须引用OurCompanyLibrary的“构建程序集”。

这意味着：

您必须在某个地方创建一个位置，用于存储其他组件引用的所有组件的构建程序集。维护构建周期以按正确顺序发布所有内容。
利用新的标准Nuget，设置一个内部的Nuget服务器（非常容易做到），并为将被其他人引用的组件构建自己的Nuget包。
最简单的方法是在解决方案中包含所有内部开发的依赖项，以确保它们在需要时进行构建。这很容易做到，但您的Application1项目将包含大部分VS项目。我不认为这是一种好的或坏的方式，这取决于您。有时候，最简单的方法也是最好的方法。

每种方法都有其优缺点，只有您可以决定哪种是最好的方法。