unit-testing - 当构建过程使用强名称签署程序集时让 InternalsVisibleTo 工作？

Question

在我们的商店中，我们使用 Cruise Control 和 MSBuild 来自动化产品的构建，作为持续集成的一部分。

构建的一部分是对程序集进行签名，以便它们具有强名称。

在我们本地开发的项目文件中，它没有指定签名，因为它被 MSBuild 脚本覆盖。

这一切都很好，直到我决定引入需要我使用 InternalsVisibleTo 的单元测试。属性。我还开始使用一个不错的开源库，其中包含也使用这种技术的单元测试。

这意味着，在我的机器上，我可以更新 AssemblyInfo.cs使用以下语句:

[assembly: InternalsVisibleTo("MyProject.Tests.UnitTests")]

一切都很好。

但是，由于构建机器对程序集进行签名，因此检查此内容会中断构建，因此需要更新该行以使其看起来像这样:

[assembly: InternalsVisibleTo("MyProject.Tests.UnitTests, 
             PublicKey="magic key here..)"]

我有一半的想法是不签署集会并收工。但是，“签署程序集是一种最佳实践”(重复此咒语 3 次)，如果我们从中获得任何好处，我不想远程它。

我们不安装到 GAC，我们并不特别担心篡改，不必担心使用我们库的第三方，我们在更新应用程序时会立即更新所有文件。最明显的好处是支持人员无法将程序集的某些随机版本复制到运行时文件夹中，并且让事情看起来可以工作一段时间。

我不想打开涉及手动更改大约 100 个项目文件以启用签名的作品。我也不想通过将应该是内部的东西标记为公共(public)来破坏东西，我不想进入绑定(bind)重定向并且我不想删除单元测试。

我希望没有强名称的所有便利以及拥有强名称的所有好处(如果有的话)，我不想为此做很多额外的工作。那是过分的要求？

这篇文章很好地描述了问题和解决方案，但我不是一个 MSBuild 脚本专家来利用它:

http://social.msdn.microsoft.com/forums/en-US/msbuild/thread/02df643c-956a-48bd-ac01-4a1016d91032/

这个问题的正确解决方案是什么？

欢迎任何意见和讨论点。

Answer 1

使用您用来禁用签名开发人员构建的相同构造来定义编译器符号，例如。那么，在你的 AssemblyInfo.cs 中做 DO_NOT_SIGN ， 用这个:

#if DO_NOT_SIGN
[assembly: InternalsVisibleTo("MyProject.Tests.UnitTests")]
#else
[assembly: InternalsVisibleTo("MyProject.Tests.UnitTests, PublicKey="magic key here..)"]
#endif

在我个人看来，它比从构建脚本修改源代码更优雅。