始终定义 Visual Studio 2013 DEBUG 预处理器指令答案

【问题标题】：Visual Studio 2013 DEBUG preprocessor directive always defined始终定义 Visual Studio 2013 DEBUG 预处理器指令
【发布时间】：2019-10-04 11:41:07
【问题描述】：

我在 Visual Studio 2013（12.0.40629.00 更新 5）解决方案中添加了一个新项目，突然 #if DEBUG 检查已编译代码通过，即使在发布时也是如此。发布版本禁用了“define DEBUG 常量”，所有项目都构建为发布版本（如配置管理器中所示）。

我在 Google 上发现了几件事，这是一个已知的错误，可以通过卸载和重新加载项目来解决（例如 here，但这没有帮助）。

我也试过undef DEBUG，但也没有运气。

解决方案中的现有项目有效，但这个新项目无效。它是 Dotnet 标准 4.5，但将其设置为 3.5 并没有帮助。

作为发布版本中发生的情况的指示：

Visual Studio 认为它是非活动代码，但它显然已编译并执行（和调试）。

这使得发布版本变得不可能。

编辑：详细说明以下问题：这不是单元测试，但我开始怀疑是否使用了调试 DLL。为了能够发布，我迅速删除了#if DEBUG中的所有代码，甚至在编译之后，软件还试图打开调试数据库。当我重新编译debug时，就OK了。

【问题讨论】：

这当然不太可能。您不能假设调试器可以在 Release 构建中正确放置突出显示，Debug 配置的存在是为了帮助它不被混淆。工具 > 选项 > 调试 > 常规中的两个选项会影响这一点，“抑制 JIT 优化”和“使用托管兼容模式”。
代码实际执行。我可以单步执行 foreach 循环，它会执行通常在调试中执行的操作，但随后会在发布版本中执行。发布版本的最初症状是它试图打开调试数据库，这是通常不编译的代码。
如果这是一个单元测试，那么确保单元测试运行器不会尝试使用调试版本。使用 Debug > Windows > Modules 来验证 DLL 是否来自您预期的位置。使用 Explorer 查看文件时间戳，以确保 Debug 构建不会覆盖 Release 版本。使用 ildasm.exe 或您喜欢的反编译器来验证方法的代码生成。
@HansPassant 我用更多信息编辑了我的问题。
嗯，这告诉您实际上是在加载 DLL 的调试版本。不知道为什么“模块”窗口没有帮助。使用 Fuslogvw.exe 并记录所有绑定，以更深入地了解这是如何发生的。

标签： c# visual-studio

【解决方案1】：

我又遇到了这个。我不知道我是怎么做到的，但显然我添加了引用作为调试 DLL 的链接，而不是解决方案中的项目。

csproj 的这个差异解释了它：

-    <Reference Include="Bla.Utils">
-      <HintPath>..\BlaUtillLib\obj\Debug\Bla.Utils.dll</HintPath>
-    </Reference>
     <Reference Include="System" />
     <Reference Include="System.Core" />
     <Reference Include="System.Data.Entity" />
@@ -166,12 +163,19 @@
       <Project>{e2bec86c-1c02-4182-8117-740612ed9330}</Project>
       <Name>DbDAL</Name>
     </ProjectReference>
+    <ProjectReference Include="..\BlaUtillLib\Bla.Utils.csproj">
+      <Project>{6de20344-62f7-45f7-92cd-dbeb19cdc4c5}</Project>
+      <Name>Bla.Utils</Name>
+    </ProjectReference>

我不知道这是怎么回事。我不会特意浏览解决方案自己项目的 DLL。

【讨论】：