更多关于:帮助构建 VS2010 解决方案/项目和 TFS2010 [英] More on: Help Structuring VS2010 Solutions/Projects and TFS2010

问题描述

这是我们上一篇文章(帮助构建 VS2010 解决方案/项目和 TFS2010)的后续文章.

This is a follow-on post to our previous post (Help Structuring VS2010 Solutions/Projects and TFS2010).

关于如何构建 VS2010 解决方案和项目以实现最佳组织，以及如何保存和使用 TFS2010，我们有几个问题.

We have a few questions regarding how to structure our VS2010 solutions and projects for best organization, as well as to save in and use TFS2010.

目前，我们的代码结构如下:

Currently, our code is structured something like:

/OverallAppName  
OverallAppName.sln  
-/Client  
-    -/WindowsFormsProject1  
WindowsFormsProject1.sln  
-    -/WindowsFormsProject2  
WindowsFormsProject2.sln  
-/Components  
-    -/ClassLibrary1 (common library referenced by other projects)  
ClassLibrary1.sln  
-    -/ClassLibrary2  
ClassLibrary2.sln  
-    -/ClassLibrary3  
ClassLibrary3.sln  
-    -/ClassLibrary4  
ClassLibrary4.sln  
-    -/ClassLibrary5  
ClassLibrary5.sln  
-/Server  
-    -/WindowsServiceProject1  
WindowsServiceProject1.sln  
-    -/WindowsServiceProject2  
    WindowsServiceProject2.sln  
-    -/WebProject1  
    WebProject1.sln  
-    -/WebProject2  
    WebProject2.sln  

由于现在我们正在从 VSS 迁移到 TFS2010，我们希望将所有解决方案/项目构建为最高效、最合乎逻辑、最容易维护、最容易参考和最简单与 TFS2010 一起使用和构建，我们需要一些关于使用分区解决方案模型构建所有内容的最佳"方式的建议.

Since, right now, we’re in the process of moving from VSS to TFS2010, we’re wanting to structure all our solutions/projects to be most efficient, most logical, easiest to maintain, easiest to reference, and easiest to use with and build in TFS2010, and we’re needing some advice on the "best" way to structure everything with a partitioned solution model.

有什么建议吗????我们如何将所有这些不同类型的 VS2010 项目组织成一个逻辑结构，使单独的组可以处理各个部分(而不是整个解决方案)，我们仍然可以拥有项目引用，我们可以存储在 TFS2010 中并在那里构建和分支，以及遵循推荐的最佳做法"?

Any suggestions????? How can we structure all these different types of VS2010 projects into a logical structure that separate groups can work on individual pieces (not the entire solution), we can still have project references, we can stored in TFS2010 and build and branch in there, and follow "recommended best practices"?

谢谢.(抱歉，我不确定格式是否很好.)

Thanks. (Sorry, I'm not sure the formatting came out very good.)

推荐答案

虽然我很欣赏你致力于将所有内容作为一个大型解决方案的承诺，但我认为这将打败 TFS 必须提供的一些最佳功能坚持这一点，实现自动化构建的领域.

While I admire your commitment to trying to keep everything as one large solution, I think this is going to defeat some of the best features TFS has to offer in the realm of automated builds by sticking to this.

我之所以这么说是因为您可以使用由签入触发的构建来立即构建代码以证明其有效(或者更好的是，使用门控签入).这些构建的有用性与它们运行所需的时间成反比.因此，如果您有一个需要 20 分钟来构建的大型解决方案，那么它将失去这些类型构建的优势.但是，如果您有几个较小的解决方案，每个解决方案大约需要 5 分钟，那么您只会在签入时获得修改后的解决方案，并更快地知道结果.

The reason I say that is because you can use builds triggered by check-in to immediately build the code to prove it works (or better yet, use a Gated check-in). The usefulness of these builds are inversely proportional to the time they take to run. So if you have a massive solution that takes 20 minutes to build then it's going to take away from the advantages of those types of builds. If however you had several smaller solutions that took about 5 minutes each then you'll only get the modified solutions building on check-in and know the results sooner.

根据您在上面列出的内容，我倾向于为每组可以单独发布的人工制品提供解决方案.在您的示例中，可能每个客户端一个，每个 Web 应用一个，所有公共库一个.

From what you've listed above I'd be inclined to have a solution for each set of artefacts that can be released separately. In your example that's probably one for each of the clients, one for each of the web applications and one for all of the common libraries.

明智的文件夹结构与您上面的内容没有太大不同(假设我正确解释了它)

Folder structure wise it'll not be much different to what you have above (assuming I'm interpreting it correctly)

/OverallApplication
    /Clients
        /Client1
            -Client1.sln
            /Client1Project1
                -Client1Project1.csproj
            /Client1Project2
                -Client1Project1.csproj
            ...
         ...
    /Components
         -Components.sln
         /ClassLibrary1
             -ClassLibrary1.csproj
         /ClassLibrary2
             -ClassLibrary2.csproj
         ...
    /Server
        /WebApp1
            -WebApp1.sln
            /WebApp1Project1
                -WebApp1Project1.csproj
            /WebApp1Project2
                -WebApp1Project1.csproj
            ...
         ...     
    /CodeSigningKey
        -KeyPair.snk
    /ReferencedAssemblies
        /Manufacturer1
            -Manufacturer1Assembly1.dll
            ...
        ...

公共库仍然可以作为项目引用添加到服务器和客户端解决方案中.我为常见项目引入了一些新文件夹，例如代码签名密钥和引用的第 3 方程序集(例如企业库).

The common libraries can still be added as project references in the server and client solutions. I've introduced a few new folders for common items such as the code signing key and 3rd party assemblies that are referenced (such as the Enterprise Library).

最重要的是，您需要采用某种分支策略来将 Main、Dev 和 Release 代码分支分开.为此，我建议稍微阅读有关 codeplex 的 ALM Rangers 分支指南.http://vsarbranchingguide.codeplex.com/releases

On top of that you'll want to employ a branching strategy of some kind to keep Main, Dev and Release code branches separate. I recommend a little light reading of the ALM Rangers branching guide on codeplex for that. http://vsarbranchingguide.codeplex.com/releases

这篇关于更多关于:帮助构建 VS2010 解决方案/项目和 TFS2010的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！