条件AssemblyName导致c#项目总是在使用"Debug"/"Release&quo

本文关键字：quot Debug quo Release 导致 AssemblyName 项目 条件 | 更新日期: 2023-09-27 18:04:12

所以我在调试模式下构建时添加了一个"d"扩展到我的程序集名称。据我所知，在c#中这样做的标准方法是编辑。csproj文件并输入以下内容:

<PropertyGroup>
  <AssemblyName Condition="'$(Configuration)' == 'V90 Debug'">$(AssemblyName)d</AssemblyName>
</PropertyGroup>

这有预期的效果，但现在修复项目总是重建输出.dll，导致其他依赖于它的项目重新链接，等等。如果不做这个改动，我就不会有这样的问题了。

到目前为止，增加项目输出的冗长性并没有帮助。

编辑:一个额外的，重要的细节是，我们使用像"V90发布"，"V90调试"，"V100发布"等名称。以便我们可以针对不同版本的Visual Studio运行时。我用标准配置名称写了一个测试应用程序，发现我的问题在这种情况下不会发生。

条件AssemblyName导致c#项目总是在使用"Debug"/"Release&quo

您正在使用C/c++开发中的旧标准。托管代码的最大区别是没有链接器。您过去常常将链接器配置为在调试构建中使用库的"d"版本，而在发布构建中使用库的非d版本。这种机制在。net中是完全不存在的，库中的代码是在运行时动态链接的。

如果您采用这种旧策略，您将遇到的一个问题是，您将在项目的参考程序集上遇到额外的问题。没有合适的方法在不同的配置中使用不同的名称。相关程序集在项目的Reference节点中列出，这是不依赖于配置的项目的属性。这不是不可能的，您需要更多的Condition技巧来重命名引用程序集。构建依赖检查也可能受到此影响。

这实际上不是必需的，程序集的调试和发布版本将具有相同的元数据。但是如果你跳过这个，你就会在运行时遇到问题。CLR将被告知使用错误的程序集名称。技术上可以通过将程序集隐藏在子目录中并使用AppDomain来解决这个问题。AssemblyResolve事件以加载正确的。您需要一个构建后事件来重命名程序集并将其复制到此目录中。当这些程序集依赖于其他程序集时，这一切都变得很糟糕。

长话短说，你以前的标准就是不适合托管代码。

相关文章：