TFS项目具有多个Visual Studio的解决方案(TFS Project with Multi

我们的团队正在考虑使用Team Foundation Server的第11节（2012年）来管理我们的项目。目前，我们做我们的项目管理中的电子表格。我们的团队只有内部客户开发软件，并有大量的项目之间的dll共享。我们还使用SVN我们的源代码版本控制。

我们有我们的应用程序的不同部分解决方案：公用库，应用程序库（业务规则等），内网网站，互联网网站，Windows窗体。这里是我们的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)

之所以分裂代码为多个解决方案，是因为我们可以重新使用在不同情况下的应用程序库（内联网应用，互联网应用程序，应用程序的Winform）。此外，企业内部网和互联网解决方案包含多个应用程序。这是我们目前的结构。我不知道这是最好的组织结构，但它为我们工作。

与切换到TFS的问题是，一个团队项目中不能有多个VS解决方案的部分。例如，我们将成立一个TFS团队项目的应用程序1，所以我们可以有该应用程序的产品积压。应用1需要改变OurCompanyLibrary，OurCompanyIntranet和OurCompanyInternet完成申请，但是，使用TFS，将只有一个VS解决方案应用1。

下面是我们如何开发一个应用程序的示例。所有的域模型和业务规则，我们存储在OurCompanyLibrary VS解决方案。当我们开发一个应用程序，把它应用1，我们先开始创建的域模型和业务规则下OurCompanyLibrary VS解决方案的OurCompanyLibrary.Application1 VS项目。一旦域模型开发，我们转移到在OurCompanyIntranet和OurCompanyInternet VS解决方案事情UI端程序。这些解决方案是一个MVC风格的网站。 OurCompanyIntranet包含VS Web项目OurCompanyIntranet.UI包含所有的视图（.aspx文件），CSS，javasciprt等OurCompanyIntranet还包含了所有应用程序分离模型和控制器的（OurCompanyIntranet.Application1在这种情况下）。在TFS组织这成为一个问题，因为我们要为应用1一个团队项目，但该应用可以跨越多个解决方案，我们不希望通过增加相同OurCompanyIntranet和OurCompanyInternet VS解决方案到源代码管理处处有重复的代码。

你将如何在TFS组织呢？还有另一种方法，我们要组织我们的代码结构，将更有意义？在那里，任何文章或网站会导致我们在正确的方向将极大地帮助。

Answer 1:

首先，不要使用多个团队项目，这是一个巨大的错误，使每个人都在开始。对于你的团队，你开发什么的大小：一个团队项目是你所需要的。

您可以使用时有完全不同的人的两队，工作在一个完全不同的项目，用完全不同的方法/过程中的两个团队项目。

随着一个团队项目，你仍然可以：

有许多分支（相关或不相关）。
有源控制的管理你所需要的最小的水平
拆分使用区域路径（这是一个节点树）工作项目的项目为子类别（功能，技术，无论你需要）。这样你可以有一个大的产品积压的或专用的。
在整个项目或特定区域总体报告（仍在使用区域路径，但在报表服务）
相信我说，这是去的最佳途径，很多很多人（包括我的第一次）犯这样的错误使用多个团队项目，并在其后付出了代价。你需要的是一个很好的源代码管理层次结构和良好的区域路径树。

关于解决方案：

有每项目的主要组成部分的一个解决方案是不是一件坏事，开发者可以在该项目的专用子集工作，最大限度地提高生产率和降低组件之间的耦合。

但是，你仍然可以拥有引用所有的项目，这将是使用每当你需要做出改变是影响所有项目一个全球性的解决方案。拥有一个全球性解决方案也是无痛地建立整个项目的简单方法。

这里的问题是关于跨组件引用 ，如果一个组件您开发（例如应用程序1）需要您开发另一个组件（例如OurCompanyLibrary），那么它同时创建和应用1必须引用OurCompanyLibrary的“内置组件”之间的相关性。

这意味着无论是：

您必须在源代码控制存储所有将被他人引用的组件的内置组件的地方创建一个位置。保持一个构建周期，释放一切尊重的正确顺序。
利用新的标准，它是的NuGet并建立一个内部的NuGet服务器（很容易做到），并建立自己的NuGet包会被他人引用的组件。
去最简单的方法是包括所有的依赖内部开发的解决方案，以确保在需要的时候，他们都建立。这很容易做到，但你的应用程序1项目将包括大部分的VS项目。我不说这是好还是坏的路要走，它是你的电话。有时最简单的方式是最好的。

每种方法都有自己的优点/缺点，只有你可以决定哪一个是最好的去。

Answer 2:

正如你所预料到了： -

OurCompanyLibrary将是一个与解决方案。

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

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

我不知道我理解你的问题。

在OurCompanyLibrary的应用VS项目将分别可建生产自己的dll，可以再在其他两种解决方案被引用。如果问题让所有的下一个VS团队项目（OurCompanyLibrary）应用程序，那么答案将是创建一个单独的VS团队项目为每个应用程序 - 对应用1，OurCompanyLibrary2的应用2，OurCompanyLibrary1等各应用程序的开发则完全独立的，并从他人分开。

如果问题是要在不同的解决方案源的不同部分，然后将其加入该项目的解决方案来实现的。这并不意味着所有这些解决方案都具有全部源代码的，虽然。我们有类似的事情，我的工作 - 我们有一个具有2个项目的解决方案 - 我们共同的业务逻辑层和我们共同的数据访问层。我们的每一个其他解决方案都有包括这些项目。这意味着我们可以从任何解决方案编辑源代码。

我不知道是否有任何这将帮助你，但好运气吧！