1

So I'm adding a "d" extension to my assembly name when building in debug mode. As far as I can tell the standard way to do this in C# is to edit the .csproj file and put in the following:

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

That has the desired effect, but now the darn project always rebuilds the output .dll, causing other projects that depend on it to relink, etc.. Without this change, I don't have any such problem.

So far increasing the verbosity of the project output hasn't helped.

Edit: An additional, important detail is that we're using names like "V90 Release", "V90 Debug", "V100 Release" etc.. for our configurations, so that we can target different versions of the Visual Studio runtime. I wrote a test app with the standard configuration names and found my problem doesn't happen in that case.

4

1 回答 1

4

您在 C/C++ 开发中使用旧标准。托管代码的最大区别在于没有链接器。您曾经将链接器配置为在 Debug 构建中使用“d”版本的库，在 Release 构建中使用非 d 版本的库。该机制在 .NET 中完全不存在，库中的代码在运行时动态链接。大大减少了为不同构建使用不同名称的实际情况。

如果您采用这种旧策略，您将遇到的问题之一是您将在项目的参考程序集中遇到其他问题。没有像样的方法在不同的配置中使用不同的名称。依赖程序集列在项目的引用节点中，这是项目的属性，不依赖于配置。这并非不可能，您需要更多Condition技巧来重命名参考程序集。构建依赖检查也可能会受到此影响。

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

长话短说，您以前的标准对于托管代码来说并不是一个好的标准。

于 2011-08-02T21:12:53.300 回答