我不知道在给定的约束下的任何一般解决方案 – 特别是从源代码树创建许多项目.

我看到的最好的选择是通过一些脚本创建项目文件.

>手动创建一个项目(创建空项目,然后添加文件),

>将其配置为尽可能靠近(即预编译头,构建配置等)

>使用创建的.vcproj作为要创建的项目文件的骨架

一个非常简单的方法将文件列表,项目名称等与“奇怪的令牌”,并填写与您的生成器.如果你想成为好人,你当然可以使用一些XML处理库.

我们的经验：我们实际上并没有将.vcproj和.sln存储在存储库(git)中,而是一个python脚本,它与源代码树一起重新生成它们,以及VS 2008“属性表模板”(或者任何它们叫做).这有助于进行一般调整.

项目生成脚本包含有关所有项目专业的信息(例如,它们是否使用MFC / ATL,将创建DLL或EXE,要排除的文件).

此外,此脚本还包含依赖关系,它会为实际构建脚本提供信息.

这个工作相当好,问题很小：python在构建系统中需要,不要忘记重新编译项目文件,我必须学习一些python来调整一些项目.

@Michael Burr“python脚本以及您可能需要什么支持”模板“有多复杂？”

我真的不能说,因为我把任务交给了另一个开发者(他们选择了python).原来的任务是提供一个构建脚本,因为VS2008解决方案构建不足以满足我们的需求,旧的批处理文件不支持并行化. .vcproj生成以后添加.据了解,他的脚本从头开始生成.vcproj和.sln文件,但从单独的属性表中提取所有设置.

优点：

>即时添加新配置.一些项目已经有六种配置,并且对unicode支持的规划意味着考虑将它们加倍一段时间.一些尴尬的工具仍然建立为MBCS,所以一些lib现在有8个配置.从手中配置是一件痛苦的事情,现在它不再打扰我了.

>全球变化,例如移动相对的项目路径,临时文件的文件夹和最终的二进制文件,直到我们找到一个解决方案我们很高兴

>建立稳定性.合并VC6项目文件是出于各种原因的一个显着的错误来源,VC9项目文件看起来不太好.现在看起来好像孤立得更好：在属性表中编译/链接设置,脚本中的文件处理.此外,脚本主要列出了我们默认的变体,最终比项目文件更容易阅读.

一般来说：当你的项目已经建立起来,我们看不到什么大的好处,他们相当稳定,你没有真正的问题.然而,当进入未知(对我们来说：主要是VC6 – > VC9和Unicode构建)时,灵活性大大降低了实验的风险.