所以当我在调试模式下构建时，我正在为我的程序集名称添加一个“d”扩展名。据我所知，在C＃中执行此操作的标准方法是编辑.csproj文件并输入以下内容：
<PropertyGroup>
<AssemblyName Condition="'$(Configuration)' == 'V90 Debug'">$(AssemblyName)d</AssemblyName>
</PropertyGroup>
这有预期的效果，但现在darn项目总是重建输出.dll，导致依赖它的其他项目重新链接等。没有这个改变，我没有任何这样的问题。
到目前为止，增加项目产出的冗长程度并没有帮助。
编辑：另一个重要的细节是我们使用“V90 Release”，“V90 Debug”，“V100 Release”等名称来配置我们的配置，以便我们可以定位不同版本的Visual Studio运行。我用标准配置名称编写了一个测试应用程序，发现在这种情况下我的问题不会发生。
答案 0 :(得分：3)
您在C / C ++开发中使用的是旧标准。托管代码的巨大差异在于缺少链接器。您曾经将链接器配置为在Debug版本中使用库的“d”版本，这是Release版本中库的非d版本。 .NET中完全没有该机制，库中的代码在运行时动态链接。实际上，为不同的构建实际拥有不同的名称。
如果您采用这种旧策略，您将遇到的一个问题是，您将在项目的参考装配中遇到其他问题。没有合适的方法可以在不同的配置中使用不同的名称。依赖程序集列在项目的“引用”节点中，这是项目的属性，它不依赖于配置。这不是不可能的，你需要更多的Condition黑客来重命名参考组件。构建依赖性检查也可能受此影响。
这实际上不是必需的，程序集的调试和发布版本将具有相同的元数据。但是如果你跳过它，你现在在运行时会遇到问题。 CLR将被告知使用错误的程序集名称。通过将程序集隐藏在子目录中并使用AppDomain.AssemblyResolve事件加载正确的程序，技术上可以解决这个问题。您需要一个post-build事件来重命名并将程序集复制到此目录中。当这些程序集依赖于其他程序集时，这一切都会变得很难看。
长话短说，您以前的标准对于托管代码来说并不是一个好标准。