具有多个 Visual Studio 解决方案的 TFS 项目 [英] TFS Project with Multiple Visual Studio Solutions

查看：48
本文介绍了具有多个 Visual Studio 解决方案的 TFS 项目的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我们的团队正在考虑使用 Team Foundation Server v.11 (2012) 来管理我们的项目.我们目前在电子表格中进行项目管理.我们的团队只为内部客户开发软件，项目之间有很多 dll 共享.我们还使用 SVN 进行源代码版本控制.

我们为应用程序的不同部分提供解决方案:通用库、应用程序库(业务规则等)、内联网网站、互联网网站、Windows 窗体.这是我们 SVN 结构的样子

SVN-CommonLibrary(VS 解决方案)-来源-CommonLibrary.Core(VS 项目)-CommonLibrary.Security(VS 项目)-CommonLibrary.Web(VS 项目)-OurCompanyLibrary(VS解决方案)- 库(此解决方案中的项目引用了这些)-CommonLibrary.Core.dll-CommonLibrary.Security.dll-来源-OurCompanyLibrary.Application1(VS 项目)- ...-OurCompanyLibrary.ApplicationN(VS 项目)-OurCompanyIntranet(VS解决方案)(MVC框架)- 库(此解决方案中的项目引用了这些)-CommonLibrary.Core.dll-CommonLibrary.Security.dll-CommonLibrary.Web.dll-OurCompanyLibrary.Application1.dll-来源-OurCompanyIntranet.Application1(VS类库项目)- ...-OurCompanyIntranet.ApplicationN(VS类库项目)OurCompanyIntranet.UI(VS Web 项目)-OurCompanyInternet(VS解决方案)(MVC框架)- 库(此解决方案中的项目引用了这些)-CommonLibrary.Core.dll-CommonLibrary.Security.dll-CommonLibrary.Web.dll-OurCompanyLibrary.Application1.dll-来源-OurCompanyInternet.Application1(VS类库项目)- ...-OurCompanyInternet.ApplicationN(VS类库项目)-OurCompanyInternet.UI(VS Web 项目)

之所以将代码拆分成多个解决方案，是因为我们可以在不同情况下(内网应用、互联网应用、Winform 应用)重用应用程序库.此外，Intranet 和 Internet 解决方案包含多个应用程序.这是我们目前的结构.我不确定这是最好的组织结构，但它对我们有用.

切换到 TFS 的问题是一个团队项目不能在多个 VS 解决方案中包含部分.例如，我们将为 Application1 设置一个 TFS 团队项目，以便我们可以为该应用程序创建一个产品待办事项列表.Application1 需要更改 OurCompanyLibrary、OurCompanyIntranet 和 OurCompanyInternet 才能完成该应用程序，但使用 TFS，Application1 将只有一个 VS 解决方案.

以下是我们如何开发应用程序的示例.我们存储在 OurCompanyLibrary VS 解决方案中的所有域模型和业务规则.当我们开发一个应用程序时，称之为Application1，我们首先在OurCompanyLibrary VS Solution下的OurCompanyLibrary.Application1 VS项目中开始创建领域模型和业务规则.一旦开发了域模型，我们就开始在 OurCompanyIntranet 和 OurCompanyInternet VS Solutions 中对事物的 UI 端进行编程.这些解决方案是一个 MVC 风格的网站.OurCompanyIntranet 包含一个 VS Web 项目 OurCompanyIntranet.UI，其中包含所有视图(.aspx 文件)、css、javasciprt 等.OurCompanyIntranet 还包含由应用程序(在本例中为 OurCompanyIntranet.Application1)分隔的所有模型和控制器.在 TFS 中组织它会成为一个问题，因为我们想要 Application1 的团队项目，但该应用程序可以跨越多个解决方案，我们不希望通过将相同的 OurCompanyIntranet 和 OurCompanyInternet VS Solutions 添加到源代码控制来在任何地方都有重复的代码.

您将如何在 TFS 中组织这些内容?是否有另一种更有意义的方式来组织我们的代码结构?任何可以引导我们朝着正确方向前进的文章或网站都会大有帮助.

解决方案

首先，不要使用多个 Team Project，这是每个人在开始时都会犯的一个巨大错误.对于您的团队规模和您开发的内容:您需要一个团队项目.

当有两个完全不同的人组成的团队使用完全不同的方法/流程从事完全不同的项目时，您将使用两个团队项目.

通过一个团队项目，您仍然可以:

  • 有很多分支(相关或不相关).
  • 在您需要的最小级别管理源代码管理
  • 使用工作项的区域路径(它是一个节点树)将您的项目拆分为子类别(功能性、技术性，无论您需要什么).通过这种方式，您可以拥有一个大型产品待办列表或专门的产品待办列表.
  • 关于整个项目或特定区域的总体报告(仍在使用区域路径，但在 Reporting Services 中)
  • 相信我，这是最好的方法，很多人(包括我第一次)犯了使用多个团队项目的错误，然后不得不为此付出代价.您需要的是良好的源代码管理层次结构和良好的区域路径树.

关于解决方案:

为项目的每个主要组件提供一个解决方案并不是一件坏事，开发人员可以处理项目的一个专用子集，以最大限度地提高生产力并减少组件之间的耦合.

但您仍然可以拥有一个引用您所有项目的全局解决方案，并且可以在您需要进行影响您所有项目的更改时使用该解决方案.拥有全球解决方案也是一种轻松构建整个项目的简便方法.

这里的问题是关于交叉组件引用，如果您开发的一个组件(例如 Application1)需要您开发的另一个组件(例如 OurCompanyLibrary)，那么它会在两者之间创建依赖关系，Application1 必须引用构建程序集"的OurCompanyLibrary.

这意味着:

  1. 您必须在源代码管理中的某处创建一个位置，以存储其他人将引用的所有组件的构建程序集.维护一个构建周期，以按照正确的顺序发布所有内容.

  2. 利用新标准 Nuget 并设置一个内部 Nuget 服务器(非常容易做到)并构建您的为其他人将引用的组件拥有 Nuget 包.

  3. 最简单的方法是在解决方案中包含所有内部开发的依赖项，以确保它们在需要时构建.这很容易做到，但您的 Application1 项目将包括您的大部分 VS 项目.我不会说这是一个好的或坏的方法，这是你的决定.有时，简单的方法是最好的方法.

每种方式都有其优点/缺点，只有您可以决定哪种方式最好.

Our team is looking at using Team Foundation Server v.11 (2012) to manage our projects. We currently do our project management in spread sheets. Our team develops software for internal clients only and there is a lot of dll sharing between projects. We are also using SVN for our source code version control.

We have Solutions for different parts of our applications: Common Library, Application Libraries (business rules, etc), Intranet Website, Internet Website, Windows Forms. Here is what our SVN structure looks like

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)

The reason for splitting the code up into multiple solutions is because we can reuse the application libraries in different situations (Intranet apps, Internet apps, Winform apps). Also, the intranet and internet solutions contain multiple applications. This is our current structure. I'm not sure this is the best organizational structure, but it works for us.

The problem with switching to TFS is that one Team Project can't have parts in multiple VS solutions. For example, we would set up a TFS Team Project for Application1 so we could have a product backlog for that application. Application1 requires changes to OurCompanyLibrary, OurCompanyIntranet and OurCompanyInternet to complete the application but, using TFS, there would only be one VS Solution for Application1.

Here is an example of how we develop an application. All of the domain model and business rules our stored in the OurCompanyLibrary VS Solution. When we develop an application, call it Application1, we first start creating the domain model and business rules in the OurCompanyLibrary.Application1 VS project under OurCompanyLibrary VS Solution. Once the domain model is developed, we move over to program the UI side of things in the OurCompanyIntranet and OurCompanyInternet VS Solutions. These solutions are a MVC style website. OurCompanyIntranet contains a VS Web Project OurCompanyIntranet.UI that contains all of the views (.aspx files), css, javasciprt, etc. OurCompanyIntranet also contains all of the models and controllers separated by application (OurCompanyIntranet.Application1 in this case). Organizing this in TFS becomes a problem, because we want a Team Project for Application1, but that application can span multiple solutions and we don't want to have duplicate code everywhere by adding the same OurCompanyIntranet and OurCompanyInternet VS Solutions to source control.

How would you organize this in TFS? Is there another way we should organize our code structure that would make more sense? Any articles or websites out there that would lead us in the right direction would greatly help.

解决方案

First, don't use multiple Team Project, this is a huge mistake that everybody make at the beginning. For the size of your team and what you develop: one Team Project is what you need.

You use two Team Projects when there are two teams of completely different people, working on a completely different project, with a completely different methodology/process.

With one Team Project you can still:

  • Have many branches (related or not).
  • Have the administration of Source Control at the tiniest level you need
  • Split your project into sub categories (functional, technical, whatever you need) using the Area Path (which is a node tree) of Work Item. This way you can have one big product backlog or dedicated ones.
  • Overall reports on your whole project or on specific area (still using Area Path, but in Reporting Services)
  • Trust me on that, it's the best way to go and many many people (including me the first time) make the mistake to use multiple Team Project and have to paid the price thereafter. What you need is a good Source Control hierarchical structure and a good Area Path tree.

Concerning Solutions:

Having one solution per main component of your project is not a bad thing, developers can work on a dedicated subset of the project, to maximize the productivity and reduce the coupling between components.

But you still can have one global solution that reference all your projects and that will be use whenever you need to make changes that impact all your project. Having a global solution is also an easy way to build your whole project painlessly.

The issue here is about cross component references, if one component you develop (e.g. Application1) needs another component you develop (e.g. OurCompanyLibrary) then it creates a dependency between both and Application1 must reference "built assemblies" of OurCompanyLibrary.

Which implies either:

  1. You must create a location somewhere in your source control to store the built assemblies of all the components that will be referenced by others. Maintain a Build Cycle to release everything respecting the right order.

  2. Take advantage of the new standard which is Nuget and setup an in-house Nuget server (very easy to do) and build your own Nuget packages for the components that will be referenced by others.

  3. The easiest way to go is including all your dependencies developed in-house in the solution to make sure they are built when needed. It's easy to do but your Application1 project will include most of your VS Projects. I don't say it a good or bad way to go, it's your call. Sometime the easy way is the best one.

Each way has its own pros/cons, and only you can decide which one is the best to go.

这篇关于具有多个 Visual Studio 解决方案的 TFS 项目的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆