我们使用Make来编译我们的产品，包括C，C ++，Java和其他一些零碎的东西。我们尽可能地拥有将整个事物编译到源代码控制中所需的所有工具，以消除本地依赖关系并确保dev机器之间的一致性。
最近我们使用Visual Studio添加了一些用C＃编写的组件，并希望采用与Visual Studio解决方案类似的方法。归结为devenv不是一个好选择。直接调用csc.exe（正如我在使用Nant之前所做的那样）将需要在构建脚本中跟踪文件依赖性，我宁愿让Visual Studio解决方案这样做。
MSBuild似乎是一个不错的选择，虽然它在%windir%\Microsoft.NET\Framework\[version]\中的默认位置让我担心机器之间的可变性，无论是路径中的[版本]还是你都会看到两者“Framework”和“Framework64”目录。我不介意要求所有开发人员安装任何.NET框架版本，但我担心你的v3.5可能与我的不同。
有没有人有他们喜欢的解决方案？尝试过你真正不喜欢的事情吗？
答案 0 :(得分：6)
MSBuild肯定是最低摩擦力的选择。不同的fx版本在构建时并不是那么重要 - 如果你使用的fx版本比安装的更高，那么它就不会构建。在我最后一个地方，我们构建了一个以NAnt为基础的庞大的多环境构建系统，并通过NAnt的MSBuild任务连接到MSBuild。如果你只是做MS的话，MSBuild本身很好，但我们有一些MSBuild本身不支持的东西，因此是NAnt包装器。
答案 1 :(得分：1)
我同意其他人的意见。为简单起见，只需将vsvars.bat（作为Visual Studio命令提示符的批处理文件）作为构建脚本的一部分，然后MSBuild就可以正常工作。
答案 2 :(得分：0)
MSBuild是这项工作的正确工具。只需将您的框架版本与您正在使用的Visual Studio捆绑的框架版本相匹配。
32位与64位无关紧要，我不认为 - 我很确定Csc.exe的32位和64位版本可以交叉编译到另一个平台。 MSBuild项目文件（*。* proj XML文件）应包含MSBuild构建应用程序所需的所有内容。
答案 3 :(得分：0)
我们使用Nant来驱动msbuild。如果您担心框架的不同版本（尤其是Service Pack），请使用FxCop检查您是否发现了意外的依赖关系。详细信息位于this answer。