调试测试时 Moles 测试成功完成，但选择“运行测试”时 moles 主机崩溃

Question

I have an issue running some moles tests within Visual Studio 2010. Within a test fixture, I have 4 tests - which when I run them in Debug mode, they all work properly.

When I run them using "Run Tests" rather than "Debug Tests", one in particular fails and the following error is given:

Problem signature:

Problem Event Name: CLR20r3

Problem Signature 01: microsoft.moles.vshost.x86.exe

Problem Signature 02: 0.94.0.0

Problem Signature 03: 4cc31915

Problem Signature 04: mscorlib

Problem Signature 05: 4.0.0.0

Problem Signature 06: 4d53693b

Problem Signature 07: 23d7

Problem Signature 08: 33

Problem Signature 09: System.AccessViolationException

OS Version: 6.1.7600.2.0.0.272.7

Locale ID: 1033

Additional Information 1: 0a9e

Additional Information 2: 0a9e372d3b4ad19135b953a78882e789

Additional Information 3: 0a9e

Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

All of the tests involve load types and create instances dynamically, although the that fails does some additional inspection on the type by examining an attribute on the class, de-serializing xml into an instance of a type, then using that as an argument to the constructor of the type.

Not sure why that should cause any specific issues, but that's the only thing I've been able to isolate.

Any help would be greatly appreciated.

EDIT:

I initially provided the error thrown by the host, here's the error reported by the VS test runner:

The test adapter 'MolesAgentAdapter' threw an exception while running test 'Create_Returns_Configuration_When_Configured_Rule_Specifies_Configuration_Data'. Failed to read from an IPC Port: The pipe has been ended.

Answer 1

I have had the same problem many times over, but was eventually able to solve it by disabling the 'Test Impact' feature in the data and diagnostics section of the solution test run config file (*.testrunconfig)

Just go to Test Settings > Data and Diagnostics > Test Impact and untick the little checkbox.

When it is on, I get the problem you describe, when it is off, everything works just fine. Maybe the PEX team will get this resolved in the next release (I hope)