在大型项目中，Project文件非常的多，如果没有很好的规划，会造成诸如dll版本不一致，打开的Project太多编译缓慢的问题，这都直接影响了工作效率。
下面我将简要介绍我们在开发大型项目中，Visual Studio Project是如何规划的，从而规避很多的问题，提高工作效率。（注：此文仅适用适用Visual Studio开发的项目，对于其他项目可能需要修改）
下面的所有实践都需要一个小工具，我叫他“项目工具”，这里我没有办法提供此工具，但你们的团队完全可以按照文章中的实践方案编写出自己的软件。
规律
在任何软件项目的活动中，均遵循下面的规律：
这里的产品单元你可以认为是一个较大的，独立管理的单元，在一个产品单元中，我们总是引用一些已有成果，例如C#项目中引用第三方组件。产品单元最重要的部分是源代码，我们会不断修改他，然后通过编译的动作，又输出成新成果。当确定无误后，我们通过“发布”的动作又发布给其他的产品单元。例如产品单元1是我们的平台组件，而产品单元2是我们具体的产品。
下图演示了一个典型的产品单元活动流程（图中每个椭圆就是一个产品单元），注意，后面我们讨论到版本等活动时，会变的更复杂一些。
平台时时刻刻都在编译，但你可以选择某个稳定的时候发版给平台测试，当平台测试OK后，他就又可以发布到产品中，产品开始使用新版本的平台，同样的，你可以自由选择什么时候打包，然后交付给产品测试。当然，你可以修改为产品到产品测试，然后才是打包。这个就随你自愿了。
目录规划
在某个产品单元下，其目录的规划非常简单，根目录来看，仅包含bin和src目录。
这么简单吗？是的，为什么要搞那么复杂。我想你会又一堆的问题出现，好吧，我一一解释。
外部已有成果（例如第三方组件）和新成果（当前产品单元编译的结果）都混在在bin目录下吗？
是的，这样做有几个好处，首先当使用者获取此目录后，即可获取所有最新的组件，要知道，往往编译一个大的产品单元是很长时间的，我们一般每天两次在服务器上编译完毕后更新TFS上的此目录，这样程序员就可以免去很多编译的时间。其次，外部组件和内部组件都放在bin的话，程序员引用dll就很方便，不必费力的在多个目录去引用，这时我最喜欢这样设计的目的。
bin下为什么没有debug和release目录
是的，正如我第一点所说，我不希望C# project在引用dll时还要如此复杂。当我真的需要一个release版本时，我通常只是调整编译参数，编译，覆盖现有组件，最后上传tfs，通过某个标签我就知道哪个是release版本。
（这里的tfs指的是Microsoft Team Foundation Server，如果你使用SVN这样的工具，本文也同样适用）
当然，如果你是一个偏执狂，我可以告诉你一个秘诀，使用记事本打开你的project源代码，然后像我这样修改，就可以动态引用一个dll了。
好吧，我有些扯远了，在下面的项目规划上我会再详细说的。
src目录存放所有源代码，我们现有的方式是src下一级存放大模块，例如薪资、供应链、财务等，然后在此目录下再建各个项目，这样不至于上千的项目放在一个目录下难于查找。 你可能会问，为什么不将这些模块作为不同的产品单元，我当然想了，可是我不得不承认一件事情，这些模块都是互相引用，很难说谁更底层一些，虽然我们可以将这些模块的接口和实体部分提取出来作为独立的产品单元，可是管理成本也是我们在乎的，所以我们将他们放在一个产品单元，只不过通过建立两级目录来隔离一下。
那么，我的设计文档、帮助文档放在哪里？
可以放在src平级，也可以放在src的子目录，这个要看个人喜好了，我没有发现这两种方式有什么优劣势。我自己喜欢src平级的目录，因为我不喜欢目录太深。
当多个产品单元需要维护时，建立多个平齐的根目录即可（就是上例的Demo Solution）。