大型.NET项目的目录、编译和版本管理实践 三

日常工作

更新组件

每个程序员在开始新的工作前，都应该先更新最新的组件，如果更新所有的源代码其实是非常耗时的动作，所以我们会仅更新最新的成果（即当前产品单元下bin目录文件），以及你当前已经打开的项目源代码。如果通过“项目工具”添加一个现有项目到解决方案，也会询问是否获取最新版本。

由于之前做了大量的准备工作，所以更新非常容易，但我们仍然认为此动作太常用，所以在工具栏上包含了此按钮，他会通过TFS强制下载最新的bin目录文件。然后会将所有文件的只读属性去掉，为什么要这么做呢？不然你编译就无法覆盖这些只读文件了，这也是我为什么强调是“强制下载”的原因。

有些时候，服务器上发布的版本有些问题，所以你可能希望获得昨天的版本，TFS正好提供了这个特性，因此此按钮还允许你选择一个特定的版本。

编译和调试

我们每天都需要做很多次的源代码修改，然后编译他，调试，最后成功后发布或者定期自动发布。

调试，或者说让程序跑起来（Run），你可能认为直接按F5不就结了（F5是VS调试的快捷键）。如果你是项目只有一个exe和一堆dll，那么可能的确是这样。但我们现在讨论的是大型项目，所以就稍微复杂点点了，比如平台组的程序员，他编译更新的只是部分组件，即其bin目录下也只是部分dll，要跑起来需要有完整的运行环境。再比如，平台的组件可能作为很多的产品底层，因此运行需要决定运行哪个产品，这就又需要“项目工具”了。

第一个按钮是运行，第二个是编译，大家都知道的我就不罗嗦了。关键是第三个文本框，他可以录入一个路径，他就是你运行时目录。当编译时，工具先编译解决方案（跟你点击VS的Build效果一样），然后再执行一段自定义的MSBuild过程，他的任务是将编译更新的成果（例如dll）按照自定义的规则复制到运行目录下。这个自定义的MSBuild过程其实是解决方案相同目录下的一个UpdateRuntime.proj的文件，每个产品单元会手工编写这个文件完成这个任务。

这种方式有个小小的问题，如果你的bin目录下的文件和子目录太多太多，这个自定义过程可能时间稍长。一方面，可以默认仅复制上次更新之后的文件，减少复制时间。另外一方面可以通过减少目录的文件和层次达到，例如将大量琐碎的图片资源文件打包成一个zip文件，这样减少了文件的数量也就减少了复制的时间。

这个运行按钮也有一点点不一样，由于有些产品单元根本没有exe可以运行，例如平台的代码就没有，所以他通过让VS启动某个特定的Exe来启动调试，附加的好处是仍然可以使用VS的“编辑并立即运行”功能。

发布

发布包括内部发布和依赖成果更新两种，内部发布是指产品单元内部始终保持尽可能新的组件，通常的，内部发布的工作都是定时执行的，只是偶尔某个版本发布的有问题，我们才会手工执行一次发布的过程。他就是一个MSBuild的自定义文件，存放在特定的目录下，让TFS定时执行，他获取此产品单元的所有最新文件，签出bin目录，然后编译，确认无编译错误后签入最新组件。

依赖成果更新相对基础产品单元来说就是外部发布，对于上层产品单元来说是一次依赖成果的更新。当依赖的基础产品单元完成内部发布并确认无误后，向本产品单元更新最新成果的过程，过程是：

• 下载依赖产品单元的最新bin成果，例如下载平台的最新组件；
• 签出本产品单元bin目录，然后复制，例如具体ERP产品签出bin目录，再将平台的最新组件覆盖ERP的bin目录；
• 签入最新组件。

由于这种更新必须是谨慎的，所以我们都是手工启动任务，他一样是一个MSBuild文件。