今天花了一天的时间来重整XFramework项目在TFS中的结构如何方便代码管理、自动编译部署以及开发。
先说MSBuild，本来这个自动编译工具提供了很详细的配置选项可以实现很多灵活的配置，虽然用工具向导出来的是一个非常简单的，只是以一个解决方案为准的编译方案。我也没有那么多时间去深入研究它的配置（估计和NAnt也不会有太大差别），但有一个问题一直不能较好的解决：
我的项目中使用了一些DLL类库的配置文件，VS2005比VS2003有所改进会把类库项目的App.Config自动的复制到编译目录，并改名为：项目名.DLL.Config，但还是有一个问题就是如果该项目被引用，配置文件并不会跟随一起被复制。在使用MSBuild之前，我都是在类库项目的编译完成事件里添加复制脚本，把配置文件复制到需要的目录中去。
可是在MSBuild中编译的时候出现了一个问题：MSBuild的编译输出目录并不是默认的每个项目的bin\Debug目录下，而是把整个解决方案的程序集都输出到一个统一的目录下去了。估计这样做的原因是为了方便打包发布。这下就糟糕啦，复制脚本的目录路径肯定就对不上了，所以MSBuild总会出错。
我一开始是把项目中的复制脚本去掉，这样MSBuild是没有任何问题啦，编译出来的文件输出都在一个目录中，自然也就包含了配置文件，运行也不会有任何问题；但是这个时候开发编译就出现了麻烦，因为项目没有复制必要的配置文件，导致开发的时候编译调试总是会出错。一想到每次修改配置文件后都要手动的去复制分发文件实在是一件非常头痛的事情，太麻烦了。
想了半天，发现编译完事件的脚本其实就是命令行脚本，应该和DOS时代的批处理脚本是一样的，那么就是可以用IF判断的，那么就可以在编译的时候判断当前编译是开发编译还是MSBuild的编译状态，只有在开发编译时才去复制配置文件。于是就这样很好的解决了问题。脚本如下：
if "$(ConfigurationName)" == "Debug" COPY $(BuiltOuputPath)..\CommAssembly\CommonSupport.dll.config $(BuiltOuputPath) /y
嘿嘿，姜还是老的辣啊，十年多前DOS时代学的东西还是有它的价值的嘛。
先说MSBuild，本来这个自动编译工具提供了很详细的配置选项可以实现很多灵活的配置，虽然用工具向导出来的是一个非常简单的，只是以一个解决方案为准的编译方案。我也没有那么多时间去深入研究它的配置（估计和NAnt也不会有太大差别），但有一个问题一直不能较好的解决：
我的项目中使用了一些DLL类库的配置文件，VS2005比VS2003有所改进会把类库项目的App.Config自动的复制到编译目录，并改名为：项目名.DLL.Config，但还是有一个问题就是如果该项目被引用，配置文件并不会跟随一起被复制。在使用MSBuild之前，我都是在类库项目的编译完成事件里添加复制脚本，把配置文件复制到需要的目录中去。
可是在MSBuild中编译的时候出现了一个问题：MSBuild的编译输出目录并不是默认的每个项目的bin\Debug目录下，而是把整个解决方案的程序集都输出到一个统一的目录下去了。估计这样做的原因是为了方便打包发布。这下就糟糕啦，复制脚本的目录路径肯定就对不上了，所以MSBuild总会出错。
我一开始是把项目中的复制脚本去掉，这样MSBuild是没有任何问题啦，编译出来的文件输出都在一个目录中，自然也就包含了配置文件，运行也不会有任何问题；但是这个时候开发编译就出现了麻烦，因为项目没有复制必要的配置文件，导致开发的时候编译调试总是会出错。一想到每次修改配置文件后都要手动的去复制分发文件实在是一件非常头痛的事情，太麻烦了。
想了半天，发现编译完事件的脚本其实就是命令行脚本，应该和DOS时代的批处理脚本是一样的，那么就是可以用IF判断的，那么就可以在编译的时候判断当前编译是开发编译还是MSBuild的编译状态，只有在开发编译时才去复制配置文件。于是就这样很好的解决了问题。脚本如下：
if "$(ConfigurationName)" == "Debug" COPY $(BuiltOuputPath)..\CommAssembly\CommonSupport.dll.config $(BuiltOuputPath) /y
嘿嘿，姜还是老的辣啊，十年多前DOS时代学的东西还是有它的价值的嘛。
