我正在维护一个大型代码库，一些vcproj文件用于不同的解决方案。由于一些可怕的配置和依赖性，似乎处理一些构建问题的最佳方法是#ifdef代码，但为了做到这一点，我需要在解决方案文件级别而不是在vcproj级别设置预处理器定义。
这可能吗？
怎么做？
答案 0 :(得分：4)
选择解决方案中的所有项目。项目+属性，C / C ++，预处理器，预处理器定义。添加
/DSOLUTION=$(SolutionName)
您现在可以在源代码中测试SOLUTION宏值。
答案 1 :(得分：4)
我相信您可能想要做的是创建一个项目属性表，其中包含所有项目都可以继承的VS Project Manager。这将允许您在一个位置设置任何常见的项目设置，包括预处理器宏，并根据需要继承它们。
答案 2 :(得分：3)
我终于找到了适合我的事情
在我的＆＃34; C：\ Users \\ AppData \ Local \ Microsoft \ MSBuild \ v4.0＆＃34;
我改变了一点：
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(SolutionDir)\$(SolutionName).props" Condition="Exists('$(SolutionDir)\$(SolutionName).props')"/>
</Project>
现在，如果一个＆＃34; mysolution.props＆＃34;放在＆＃34; mysolution.sln＆＃34;旁边。然后我得到整个解决方案的属性表，而不会改变我的项目内的任何内容。它成为我的Visual Environement的新功能
答案 3 :(得分：1)
2008 sln真的很蠢，他们只有项目/文件列表放在解决方案资源管理器和项目依赖项中，所以我不认为这是一个选项。
我的直觉是用相对路径做点什么。例如，在你的stdafx.h中，你可以#include“.... \ project_configuration.h”，然后为了构建sln a，你可以检查一个目录，然后另一个。每个都有其独立的project_configuration.h。
我相信你可以用vsprops文件做类似的事情，对于vcproj文件基本上都是#includes，尽管我发现它们有点烦人的维护。
答案 4 :(得分：1)
另一个问题：
使用类似
的内容编辑vcxproj（或vcxproj.user）.filter()它不完美，因为它取决于你的sln文件名。 如果我们使用$（SolutionConfiguration）变量，那就太棒了。
不幸的是，我只看到项目配置的变量：$（Configuration）。
无论如何，它都有诀窍......
答案 5 :(得分：0)
好吧，我也看了
Define a preprocessor value from command line using MSBuild
和
msbuild, defining Conditional Compilation Symbols
并且那些可能也可以，但是我们的构建系统现在非常脆弱，我无法改变它。
我想出的解决方案是在解决方案中克隆项目的构建配置，并为其命名。然后我为这个新配置添加了一个宏/预处理器定义。
似乎可以按预期工作。因此，一个解决方案使用旧的“发布”配置，另一个解决方案使用克隆“ReleaseSpecial”（不是我真正使用的名称）配置与不同的预处理器defs。
不理想，但有效。
如果这些propoerties更容易处理或者SLN文件可以在预处理器defs中传递，那将是很好的。