我使用Visual Studio 2017（但适用于2010年以后的任何版本），并且我一直在努力想出一种方式来组织我的Debug / Release库，从而避免我们遇到的所有这些链接错误，当混合使用不同版本的运行时库时。从概念上讲，我的目标似乎很简单，但是我还没有找到一种实现我想要的一切的方法。
这就是我所拥有的，我想做的：
公用库：
ComLib1
ComLib2
...
Exe1：
ComLib1
ComLib2
...
Exe1Lib1
Exe1Lib2
...
exe1
Exe2：
ComLib1
ComLib2
...
Exe2Lib1
Exe2Lib2
...
exe2
使用一组通用库和特定于Exe的库，所以有2种不同的可执行文件。
我想创建4种不同的构建配置。
Cfg1：
这将包含所有库（包括公共库）的调试信息/未优化的代码。
Cfg2：
这将包含所有特定于Exe的库的调试信息/未优化的代码，但不包含公共库的调试信息/未优化的代码。
Cfg3：
这将包含一些库的调试信息/未优化代码库和其余库的未调试信息/未优化库的组合。
cfg4：
你猜到了。这将包含所有非调试信息和优化代码。
我的第一步是基本上为每个库创建2套二进制文件。一个在Debug模式下（使用/ MTd / Od）进行编译，而另一个在Release Mode下使用（/ MT / O2）进行编译。然后在我的各种配置中选择一个或另一个版本。这对于Cfg1和Cfg4很好（因为所有运行时库在整个过程中都是一致的），但是遇到了那些与Cfg2和Cfg3链接错误的问题。
我了解为什么会出现这些错误。我只是不确定如何解决这些问题，我认为这是一种常见的情况。也许Cfg3并不常见，但我认为Cfg1,2和4是。
感谢您的输入。
编辑
我真的不认为我需要添加此信息，因为我想使问题简短一些。但是，如果可以帮助阐明我的目标，我将其加总。
这是针对实时模拟器的。我只是不能在典型的Debug配置中运行每个库，因为我无法维护Realtime。我很少需要调试公共库，因为它们主要与服务器/ IO任务相关。 Exe库主要包含数学/热力学，也是我大部分时间都在其中度过的地方。但是，1 Exe lib包含反应堆中子学，其中涉及大量计算。我们通常将其视为黑匣子（供应商提供的加密代码），我几乎总是想使用优化代码（典型的发行版设置）来运行它。
答案 0 :(得分：1)
如果没有一些特殊考虑，就不能在同一进程中使用不同的运行时库（例如，使用DLL或在接口中没有CRT对象的情况下将它们完全分开），而不会出现链接错误，也不会冒CRT对象在运行时出现问题的风险在之间传递。
您可以将模块中的大多数常规优化选项与明显不同的异常混合在一起，并且链接时间代码生成对于所有对象都必须相同。只要未优化您自己的代码，发行版运行库通常也可用于调试。
要轻松切换，您需要针对每种情况的解决方案配置（如此4）。如果您不希望某些项目重复，但是可以遵循多个限制，则可以使一个项目配置被多个解决方案配置所使用，但是它必须遵循前面提到的限制，并且可能会使输出目录等问题感到困惑。您还可以使用属性表在多个项目和配置之间共享设置。
答案 1 :(得分：0)
我对输出目录路径或目标文件名使用预定义的宏做过类似的事情。
例如，我使用$(Platform)_$(Configuration)扩展为Win32_Debug或Win32_Release。
您也可以使用环境变量。我还没有尝试使用预处理器宏。
在Internet上搜索“ MSDN Visual Studio预定义宏$（Platform）”。
答案 2 :(得分：-1)
所以这就是我最终得到自己想要的东西的原因。
假设我使用的是静态运行时库，我想我将为我的Common Libraries保留典型的Debug / Release（分别为/ MTd和/ MT）库，并为我的Exe创建3套库：
Exe1Lib1Release：典型发行版配置
Exe1Lib1Debug：典型的调试配置
Exe1Lib1DebugMT：未优化的代码，带有调试信息，但使用MT运行时库
Cfg1：
将会在
Cfg2和Cfg3：
将对公共库使用典型的Release库，对Exe的库使用Exe1Lib1DebugMT
cfg4：
将在各处使用典型的发布库。
编辑
实际上，Cfg2和Cfg3设置可以更准确地表示为：
Cfg2：
将对公共库使用典型的Release库，对Exe的库使用Exe1Lib1DebugMT
Cfg3：
将为公共库使用典型的Release库，并为Exe的库使用Release和Exe1Lib1DebugMT的组合