c# - 带有假货的单元测试中的 Visual Studio 2015 InvalidProgramException

Question

我正在使用 Visual Studio 2015 Enterprise RTM 为使用 Unity Container 的项目编写单元测试.

我发现为 Unity 添加一个伪装程序集的简单操作，甚至没有实际使用该伪造程序集，就足以生成此异常:

System.InvalidProgramException: Common Language Runtime detected an invalid program.

请考虑以下重现步骤:

• 使用 Visual Studio 2015 Enterprise RTM 创建一个面向 .NET 4.6 的单元测试项目

• 添加 NuGet 包“Unity”版本 3.5.1404.0

• 添加 NuGet 包“CommonServiceLocator”版本 1.2.0

• 像这样写一个单元测试:

[TestClass]
public class UnitTest1 : IDisposable
{
    [TestMethod]
    public void TestMethod1()
    {
        new ResolvedArrayParameter<IDisposable>(new IDisposable[] {this});
    }

    void IDisposable.Dispose()
    {
    }
}

• 验证测试通过

• 右键单击 Microsoft.Practices.Unity 引用并选择“添加假程序集”

• 重新运行测试

• 观察以下显着的测试失败:

Test Name: TestMethod1
Test FullName: UnitTestProject11.UnitTest1.TestMethod1
Test Source: c:\temp\UnitTestProject11\UnitTestProject11\UnitTest1.cs : line 12
Test Outcome: Failed
Test Duration: 0:00:00.0572447

Result StackTrace:

at Microsoft.Practices.Unity.ResolvedArrayParameter..ctor(Type arrayParameterType, Type elementType, Object[] elementValues)
at Microsoft.Practices.Unity.ResolvedArrayParameter`1..ctor(Object[] elementValues)
at UnitTestProject11.UnitTest1.TestMethod1() in c:\temp\UnitTestProject11\UnitTestProject11\UnitTest1.cs:line 13
Result Message:
Test method UnitTestProject11.UnitTest1.TestMethod1 threw exception:
System.InvalidProgramException: Common Language Runtime detected an invalid program.

这个问题最不寻常的特点显然是伪造甚至不需要直接出现在代码中就可以显示失败。

大量的摆弄表明，将测试项目重新定位到 .NET 4.5“修复”了这个问题，这对我来说是不可能的，因为 another我几周前发布的问题。

几乎所有的伪造设置(代码契约等)都没有解决。

如有任何关于此问题的建议，我们将不胜感激。

Answer 1

唯一的通用解决方案是确保所有部分都与您正在使用的 CLR 版本非常匹配，并且 VS 具有最新更新。

这个问题没有 Elixir 。当您注入(inject)假货时，您需要知道(挖掘)项目中连接的所有部分的确切 CLR 版本兼容性。请注意，“兼容性”可能只是 list 问题，但更常见的是最终代码是如何生成的以及虚拟机版本的细微差别。

这些事情对于运行和调试通常无关紧要，因为有多个层可以确保次要版本差异无关紧要，或者您可以静默切换到声明兼容的任何代码。

但是，当您使用 Fakes 时，“系统”会将原始代码注入(inject)您的(包括涉及的第 3 方库)，这意味着它会跳过大多数检查 - 否则无法工作。但是，当实际运行代码时，引擎(虚拟机)必须对其自身的安全性/完整性进行一些检查，如果声明看起来不够匹配，它往往会变得偏执并退出。

这就是为什么有人问所涉及的程序集是否具有强名称或签名的原因。这是“系统”真正信任的唯一保证级别。否则它会进行一定程度的猜测，虽然对于代码注入(inject)来说它很重要，但对于正常运行来说通常无关紧要。

我仍然没有谈论可能的实际问题 - 这都是假设实际代码很好，只是声明很困惑。您可以尝试使用它，但这会花费大量时间和精力。检查是否可以获得更匹配的程序集版本要容易得多。

当您将 flavor 切换回 4.5 时错误消失的事实告诉您，涉及的某些程序集对于 4.6 来说“不够接近”，或者代码注入(inject)可能存在一些故障，这些故障已通过您没有的更新修复尚未接受。

是的，这会带来很多痛苦，但这是想要站在前沿的代价。