伪造的单元测试中的Visual Studio 2015 InvalidProgramException [英] Visual Studio 2015 InvalidProgramException in Unit Test With Fakes

问题描述

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

I am using Visual Studio 2015 Enterprise RTM to write unit tests for a project that uses Unity Container.

我发现，只需为Unity添加一个假程序集，甚至不实际使用 假程序，就足以生成此异常:

I have discovered that the simple act of adding a fakes assembly for Unity, not even actually using the fake, is sufficient to generate this exception:

System.InvalidProgramException:公共语言运行时检测到无效程序.

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

请考虑以下步骤来重现:

Consider the following steps to reproduce:

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

• Using Visual Studio 2015 Enterprise RTM create a Unit Test project targeting .NET 4.6

添加NuGet包"Unity"；版本3.5.1404.0

Add the NuGet package "Unity" version 3.5.1404.0

添加NuGet包"CommonServiceLocator"；版本1.2.0

Add the NuGet package "CommonServiceLocator" version 1.2.0

像这样编写单个单元测试:

Write a single unit test like so:

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

    void IDisposable.Dispose()
    {
    }
}

• 验证测试通过

  • Verify the test passes

    右键单击 Microsoft.Practices.Unity 参考，然后选择添加假冒程序集"

    Right click on the Microsoft.Practices.Unity reference and choose "Add Fakes Assembly"

    重新运行测试

    观察以下明显的测试失败:

    Observe the following remarkable test failure:

    测试名称:TestMethod1
    测试全名:UnitTestProject11.UnitTest1.TestMethod1
    测试源:c:\ temp \ UnitTestProject11 \ UnitTestProject11 \ UnitTest1.cs:第12行
    测试结果:失败
    测试时间:0:00:00.0572447
    

    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
    

    结果StackTrace:
    
    在Microsoft.Practices.Unity.ResolvedArrayParameter..ctor(Type arrayParameterType，Type elementType，Object [] elementValues)
    在Microsoft.Practices.Unity.ResolvedArrayParameter`1..ctor(Object [] elementValues)
    在c:\ temp \ UnitTestProject11 \ UnitTestProject11 \ UnitTest1.cs中的UnitTestProject11.UnitTest1.TestMethod1()中:第13行
    结果消息:
    测试方法UnitTestProject11.UnitTest1.TestMethod1引发异常:
    System.InvalidProgramException:公共语言运行时检测到无效程序.
    

    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.
    

    此问题的最不寻常的特征是，假冒甚至不必为了无法显示而直接出现在代码中.

    The most extraordinary feature of this problem is evidently fakes don't even need to appear directly in the code for the failure to manifest.

    大量的摆弄表明，将测试项目重新定位为.NET 4.5修复".这个问题，因为另一个问题，对我而言这不是入门几周前发布了.

    An extensive amount of fiddling reveals that retargeting the test project to .NET 4.5 "fixes" the problem, which is a non-starter for me because of another issue I posted some weeks back.

    几乎所有伪造设置(代码合同等)的摆弄都没有解决方案.

    Even more fiddling with virtually all fakes settings (code contracts, etc.) yielded no solution.

    在此问题上的任何建议将不胜感激.

    Any advice on this issue would be very much appreciated.

    推荐答案

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

    The only general solution is to make sure that all parts match the version of CLR you are using very closely and that VS has the latest updates.

    没有解决此问题的灵丹妙药.当您注入伪造品时，您需要知道(挖掘)项目中连接的所有部分的确切CLR版本兼容性.请注意，兼容性"可能只是清单的问题，但更常见的是，它们是如何生成最终代码以及为虚拟机的哪个版本生成细微差别的问题.

    There is no magic bullet for this problem. You need to know (dig out) the exact CLR version compatibility of all parts that are connected in your project when you inject fakes. Mind you that "compatibility" might be just the matter of manifest but more frequently they are the matter of nuances of how was/is the final code generated and for which version of the virtual machine.

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

    These things normally don't matter for running and debugging since there are several layers that make sure that minor version differences either don't matter or you get a silent switch to whatever your code is declared to be compatible with.

    但是，当您使用Fakes时，系统"会将原始代码注入您的代码(包括涉及的第三方库)，这意味着它将跳过大多数检查-否则将无法正常工作.但是，当需要实际运行代码时，引擎(虚拟机)必须对其自身的安全性/完整性进行一些检查，如果声明之间的匹配程度不够高，则它往往会产生偏执并陷入困境.

    But, when you use Fakes, the "system" injects raw code into your (which includes 3rd party libraries involved) and that means that it skips most checks - couldn't work otherwise. But, when the time comes to actually run the code, the engine (virtual machine) has to do some checks for it's own safety/integrity and it tends to get paranoid and bail out if it looks like declarations don't match closely enough.

    这就是为什么有人问所涉及的程序集是强名称还是签名的原因.这是系统"真正信任的唯一保证.没有它，它将进行一定程度的猜测，而对于代码注入而言，对正常运行几乎没有关系.

    This is the reason why someone asked whether assemblies involved are strongnamed or signed. That's the only level of guarantee that "system" will really trust. Without that it will do a degree of guessing and while it mostly doesn't matter for normal runs if matters a lot for code injection.

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

    I'm still not talking possible real problems - this is all assuming that actual code is fine and just declarations are confused. You could try to play with that but it would take a lot of time and effort. Much easier to go checking if you can get versions of assemblies that are better matching.

    当您将风味切换回4.5时错误消失的事实告诉您，其中某些程序集对于4.6而言不够紧密"，或者代码注入可能存在一些毛刺，这些毛刺已通过您尚未进行的更新得到了解决.还没收.

    The fact that errors vanished when you switched your flavor back to 4.5 tells you that either some of the assemblies involved are not "close enough" for 4.6 or there can be some glitches with code injection that were fixed by updates you haven't taken in yet.

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

    Yes it involves a lot of pain but that's the price of wanting to be at the frontier.

    这篇关于伪造的单元测试中的Visual Studio 2015 InvalidProgramException的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！