Hi,
It can be difficult to tell why the CLR would have trouble loading the mixed mode assembly at run-time. My first thought is that the CLR may be behaving very differently when loading this assembly due to it being structurally different to a normal .NET assembly.
When the pre-load assembly references setting is disabled, NCrunch will attempt to direct the CLR to a test environment's dependencies passively by hooking events into the test application domain and serving up the assembly when the CLR fails to find it. The CLR almost always fails to find assemblies for the NCrunch test environment in its initial pass - this is by design, as the only reliable point at which NCrunch can intercept the request for an assembly is after the CLR has completed its normal scanning logic (which involves the GAC, the current directory, etc).
When the pre-load assembly references setting is enabled, NCrunch will load all the dependencies of a test environment into the application domain before it starts executing tests. Because it can tell the CLR exactly where to find the assemblies, there is never any ambiguity around which assemblies are loaded, nor is there any reliance on the CLR's implicit assembly loading logic.
Normally the need to turn on pre-loading of assembly references stems from the need to prevent the CLR from loading the wrong assembly. This can happen in certain situations where the 'copy referenced assemblies to workspace' is enabled and different versions of the same assembly are being used in the solution.
The only situation I can think of where pre-loading of assembly references actually ALLOWS the CLR to find an assembly that passive searching wouldn't normally find is if the CLR were behaving strangely around the resolution of assemblies, and wasn't correctly invoking the resolution events before declaring that the assembly couldn't be found. If this is indeed the case, then there is no way for NCrunch to passively serve up this dependency and switching on the pre-load assembly references setting will be the only way that this problem can be solved.
It might be possible to get more information about this by turning on Fusion logging and taking a look a the fusion logs. Often these logs can be quite revealing around assembly reference issues.
