关于C#：在Visual Studio(2005)下使用Makefile代替Solution / Project文件

Using Makefile instead of Solution/Project files under Visual Studio (2005)

与使用项目/解决方案安装程序相比，是否有人有使用Visual Studio C构建(在VS 2005下)生成文件的经验。对于我们来说，项目/解决方案的工作方式不直观，当您尝试使用特定的编译时标记来调整构建时，会导致配置爆炸。

在Unix下，很容易设置一个makefile，该文件的默认选项被用户设置(或其他配置设置)覆盖。但是在Visual Studio中执行这些类型的操作似乎很困难。

通过示例，我们有一个项目需要针对3个不同的平台进行构建。每个平台可能有几种配置(例如，调试，发布和其他几种)。我在一个新成立的项目中的目标之一是拥有一个可以使所有平台构建在一起的解决方案，这使构建和测试代码更改更加容易，因为您不必打开3个不同的解决方案来测试代码。但是Visual Studio将需要3 *(基本配置数量)配置。即PC调试，X360调试，PS3调试等。

似乎makefile解决方案在这里要好得多。包裹一些基本的批处理文件或脚本，可以很容易地将配置展开次数降至最低，并且只为我们要做的所有不同构建维护一小组文件。

但是，我在Visual Studio下没有makefile的经验，我想知道其他人是否有可以分享的经验或问题。

谢谢。

(编辑后提到这是C版本)

我发现大型项目的makefile有一些好处，主要与统一项目设置的位置有关。如果它们都在makefile或其他构建配置文件中，则管理源文件列表，包括路径，预处理器定义等会稍微容易一些。在具有多个配置的情况下，添加包含路径意味着您需要确保通过Visual Studio的简单项目属性手动更新每个配置，随着项目大小的增加，这可能会变得非常乏味。

使用大量自定义构建工具的项目也可以更轻松地进行管理，例如，如果您需要编译像素/顶点着色器，或者使用其他不具有本机VS支持的语言编写的代码。

但是，您仍然需要具有各种不同的项目配置，因为您需要区分每个配置对构建工具的调用(例如，传递不同的命令行选项以进行构建)。

立即想到的缺点：

较慢的构建：VS调用外部工具的速度不是特别快，甚至无法确定是否需要首先构建项目。
尴尬的项目间依存关系：进行设置很麻烦，以便让受抚养人使基础项目得以构建，并且灵活地确保按正确的顺序构建它们。使SCons做到这一点已经取得了一些成功，但是要使其工作正常，始终是一个挑战。
丢失了一些有用的IDE功能：编辑

Visual Studio正在MSBuild配置文件之上构建。您可以将* proj和* sln文件视为makefile。它们使您可以完全自定义构建过程。

尽管在技术上可行，但它不是Visual Studio中非常友好的解决方案。它将一直困扰着您。

我建议您看看NAnt。这是一个非常强大的构建系统，您可以在其中完成所需的任何操作。

我们的NAnt脚本在每次构建时都执行此操作：
将数据库迁移到最新版本
从数据库生成C#实体
编译我们"主"解决方案中的每个项目
运行所有单元测试
运行所有集成测试