代码项目文件规划
这里特别使用“代码项目文件”规划，我怕大家误解成在讲大型项目的项目规划，这里讲的是代码项目文件的规划，例如你使用C#开发，就是指那个*.csproj文件。
项目的输出
首选，你需要保证project输出到此产品单元的bin目录下，而不是默认的bin\debug这样的目录。打开项目的属性，下图是C#项目的设置：
1、选择“Build 生成”；
2、选择“All Configurations 所有配置”，保证Debug和Release都使用此配置；
3、选择“Output path 输出路径”，指向产品单元的bin目录。
4、如果你还有xml帮助输出，可以选择“XML documentation file XML文档文件”，也指向产品单元的bin目录对应的文件名。
Virtual Basic大同小异，我这里仅给出一幅图，注意Basic不需要专门设置XML文档文件名。
这些设置我强烈不建议手工操作，项目居多时，费时费力又容易有疏漏，建议开发小工具自动完成。
引用组件
毫无疑问，项目都应该引用bin目录下的dll，那么还有哪些注意的事项呢。下图演示了在一个C#项目中，一个引用的属性（他通过在项目引用上点击右键，选择属性获得）。
这里我将“复制本地”设置为false，因为我们从此目录引用文件，然后又复制到这个目录，是没有必要的。
我还喜欢把“特定版本”设置为false，这样只是为了方便，虽然不严谨，但很实用。
如果是引用产品单元内部的组件，是引用dll还是引用项目文件？
应该引用DLL，而不是项目文件。
我们知道，如果引用项目文件的话，好处是Visual Studio会自动分析项目的引用关系，并决定编译的先后顺序，这是一个非常好的功能。但请注意，我们这里讲的是大型.net项目，他们动辄几百个项目，如果放在一个解决方案中，显然太大了。我们总是仅加载几个我们需要的项目来调试，而这个时候Visual Studio就会在你的项目引用图标上显示一个感叹号，告诉你他找不到这个项目。虽然实践证明，VS仍然可以正常编译，但由于没有加载被引用的项目，所以VS也就不能自动调整编译顺序了。另外一个已知的问题是，如果你在解决方案中删除一个项目，那么在其他项目引用了他，VS会自作聪明的将引用删除掉。所以引用项目形同虚设。
回到引用DLL，首先引用DLL的行为变得一致。关键是在自定义的解决方案文件中，我们可以随时删除一个项目，或增加一个项目，VS不会自作聪明的删除引用了。那么如何定义编译的顺序呢？总不能程序员每次自己维护吧，当然不是，这就不得不使用文章开头提到的“项目工具”了，你必须使用此工具添加和删除项目，他会自动设置项目的编译顺序。
下图演示了“项目工具”中，引用功能的样子。
此工具的工作原理是，他事先分析此产品单元的所有引用，这样就知道先后顺序，当你在VS中添加个别项目时，他设置项目的依赖性达到此功能。还是那句话，你需要一个工具而不是手工操作。
解决方案文件
程序员在调试时，是自己建立一个解决方案文件，当他需要调试某个项目时，把他加入进来，如果调试完毕，从解决方案中移除即可。这样做显而易见的好处是内存消耗更小，编译和运行更加的快速。
此解决方案并不需要上传到TFS服务器上，那如果要编译所有的解决方案该怎么办呢？通常，我们的“项目工具”，提供一个功能，扫描产品单元的源代码目录，将所有的项目集合到一个解决方案中，分析依赖关系，最后自动创建一个all.sln文件，我们就是编译这个项目文件，TFS也是编译这个解决方案。
在VS中，新增一个Project也是通过这个工具完成的，而不是使用VS自带的新增项目功能，他主要是完成以下功能：
- 自动设置项目的输出等信息；
- 包含产品统一的版权申明，版本等信息；
- 签出all.sln文件，并加入这个项目到解决方案；
这个工具的界面看起来这个样子的，这仅是一个示例，你可以为了易用性，增加诸如搜索这样的功能。
