c# - MSpec Json.NET deserialization test fails in ReSharper but passes in NCrunch -

i have following 2 unit tests: 1 using mstest , 1 using machine specifications. far can see should behave identically. however, while first 1 passes in both ncrunch , resharper test runners, second 1 fails in resharper.

using machine.specifications; using microsoft.visualstudio.testtools.unittesting; using newtonsoft.json;  public class testmodel {     public string name { get; set; }     public int number { get; set; } }  // mstest [testclass] public class deserializationtest {     [testmethod]     public void deserialized_object_is_the_same_type_as_the_original()     {         testmodel testmodel = new testmodel() {name = "john", number = 42};         string serialized = jsonconvert.serializeobject(testmodel, new jsonserializersettings { typenamehandling = typenamehandling.objects });          object deserialized = jsonconvert.deserializeobject(serialized, new jsonserializersettings { typenamehandling = typenamehandling.objects });          // passes in both test runners         assert.isinstanceoftype(deserialized, typeof(testmodel));     } }  // mspec public class when_an_object_is_deserialized {     static testmodel testmodel;     static string serialized;     static object deserialized;      establish context = () =>     {         testmodel = new testmodel() { name = "john", number = 42 };         serialized = jsonconvert.serializeobject(testmodel, new jsonserializersettings { typenamehandling = typenamehandling.objects });     };      because of = () => deserialized = jsonconvert.deserializeobject(serialized, new jsonserializersettings { typenamehandling = typenamehandling.objects });      // passes in ncrunch fails in resharper.     should_be_the_same_type_as_the_original = () => assert.isinstanceoftype(deserialized, typeof(testmodel)); } 

the failure message is: assert.isinstanceoftype failed. expected type:<unittestproject2.testmodel>. actual type:<unittestproject2.testmodel>. oddly, following pass:

it should_be_the_same_type_as_the_original = () => assert.istrue(testmodel.gettype() == typeof(testmodel)); 

i doing deserialization in way because actual code in question needs able handle objects type unknown until runtime. assume there odd way json.net kind of deserialization, why should 2 test runners behave differently? using resharper 9.1 in visual studio 2013.

clearly there odd runtime effect going on due subtle difference in behaviour between ncrunch , resharper. failure telling wrong , shouldn't dismiss bug in either resharper or ncrunch.

when step through mspec test in debugger, deserialized object shows following error in debugger:

deserialized  cannot fetch value of field 'deserialized' because information containing class unavailable.   object 

it hard without seeing full solution, i've seen sort of thing happen when build output directory contains more 1 copy assembly, possibly in subdirectory. if different copies of assembly being referenced @ different times different components, types assembly not considered equal if identical copy of assembly. solution make sure have 1 copy of every assembly in build output, ensures referencing exact same file. json converter dynamically loading type , getting wrong assembly, or possibly loading different load context means types not considered equal copies loaded in different context.

there build environment resulting in duplicate copy of assembly in mspec case. ncruch, in particular, doesn't execute post-build events default (and shows warning effect), if copying files around in post-build step 1 explanation different behaviour. check enabling post-build events in ncrunch , seeing if failure occurs.

another possible troubleshooting step use fusion log viewer (fuslogvw.exe) log assembly binds, should able work out assemblies being loaded , in load context.

update i'm pretty sure assembly binding issue caused json converter's use of assembly @ runtime. in fusion log, found entry:

 *** assembly binder log entry  (05/06/2015 @ 02:01:38) ***  operation successful. bind result: hr = 0x0. operation completed successfully.  assembly manager loaded from:  c:\windows\microsoft.net\framework64\v4.0.30319\clr.dll running under executable  c:\users\tim\appdata\local\jetbrains\installations\resharperplatformvs12_001\jetbrains.resharper.taskrunner.clr45.x64.exe --- detailed error log follows.   log: ijw explicit bind. file path:c:\users\tim\vs-projects\stackoverflow\stackoverflow.30643046\bin\debug\stackoverflow.30643046.dll. log: ijw assembly bind returned different path: c:\users\tim\appdata\local\temp\k3dpwn5u.uii\machine specifications runner\assembly\dl3\6c41c492\c7eea8ec_279fd001\stackoverflow.30643046.dll. use file provided. 

i found one:

*** assembly binder log entry  (05/06/2015 @ 02:01:38) ***  operation successful. bind result: hr = 0x0. operation completed successfully.  assembly manager loaded from:  c:\windows\microsoft.net\framework64\v4.0.30319\clr.dll running under executable  c:\users\tim\appdata\local\jetbrains\installations\resharperplatformvs12_001\jetbrains.resharper.taskrunner.clr45.x64.exe --- detailed error log follows.   wrn: same assembly loaded multiple contexts of application domain: wrn: context: default | domain id: 2 | assembly name: stackoverflow.30643046, version=1.0.0.0, culture=neutral, publickeytoken=null wrn: context: neither | domain id: 2 | assembly name: stackoverflow.30643046, version=1.0.0.0, culture=neutral, publickeytoken=null wrn: might lead runtime failures. wrn: recommended inspect application on whether intentional or not. wrn: see whitepaper http://go.microsoft.com/fwlink/?linkid=109270 more information , common solutions issue.   *** assembly binder log entry  (05/06/2015 @ 02:04:41) ***  operation successful. bind result: hr = 0x0. operation completed successfully.  assembly manager loaded from:  c:\windows\microsoft.net\framework64\v4.0.30319\clr.dll running under executable  c:\users\tim\appdata\local\jetbrains\installations\resharperplatformvs12_001\jetbrains.resharper.taskrunner.clr45.x64.exe --- detailed error log follows.   wrn: same assembly loaded multiple contexts of application domain: wrn: context: default | domain id: 2 | assembly name: stackoverflow.30643046, version=1.0.0.0, culture=neutral, publickeytoken=null wrn: context: neither | domain id: 2 | assembly name: stackoverflow.30643046, version=1.0.0.0, culture=neutral, publickeytoken=null wrn: might lead runtime failures. wrn: recommended inspect application on whether intentional or not. wrn: see whitepaper http://go.microsoft.com/fwlink/?linkid=109270 more information , common solutions issue.   *** assembly binder log entry  (05/06/2015 @ 02:04:42) ***  operation successful. bind result: hr = 0x0. operation completed successfully.  assembly manager loaded from:  c:\windows\microsoft.net\framework64\v4.0.30319\clr.dll running under executable  c:\users\tim\appdata\local\jetbrains\installations\resharperplatformvs12_001\jetbrains.resharper.taskrunner.clr45.x64.exe --- detailed error log follows.   wrn: same assembly loaded multiple contexts of application domain: wrn: context: default | domain id: 2 | assembly name: stackoverflow.30643046, version=1.0.0.0, culture=neutral, publickeytoken=null wrn: context: neither | domain id: 2 | assembly name: stackoverflow.30643046, version=1.0.0.0, culture=neutral, publickeytoken=null wrn: might lead runtime failures. wrn: recommended inspect application on whether intentional or not. wrn: see whitepaper http://go.microsoft.com/fwlink/?linkid=109270 more information , common solutions issue. 

i found disabling resharper unit test option "shadow copy assemblies being tested" results in test passing.

so think have 'smoking gun'. have conflicting assembly loads because of way you're letting json deserializer discover type @ runtime.

update 2015-06-11

i noticed this on mspec mailing list, might relevant issue: [machine.specifications] shadow copying broken - creates subtle bugs in tests