Hi, thanks for sharing this issue.
NCrunch is heavily dependent on the assembly resolution logic inside the CLR and MSBuild. Unfortunately, the rules that govern assembly resolution for both of these platforms are very complex. This makes it difficult to know exactly how the build or test appdomain will behave in every situation, as there is no reliable way to 'force' MSBuild/CLR to use a specific assembly. NCrunch tries, but there is too much implicit logic for this to be completely reliable.
When resolving any assembly reference, the CLR's first preference is always to attempt to load this assembly from the GAC. This will override all other forms of referencing. In your case, I suspect it's likely that the reference from your project to the SharePoint DLL wasn't specifying a strong preference for the version of the DLL. This meant that MSBuild was just taking its first preference, which would later conflict with other assembly references downstream in the build process. The natural solution is to try and be consistent with how you reference DLLs and to make sure you specify the version where there may be ambiguity.
It is unfortunate that NCrunch needs to sit on top of platforms that exhibit such a range of behaviour. The techniques used by NCrunch to allow it to build projects in isolation can sometimes make subtle changes in the way that the build executes when compared with a normal VS build of your solution. It's rare that these differences cause serious problems, but sometimes you do get things floating to the surface in the NCrunch build that the VS build won't have flagged up - and vice versa.
If you'd like to take a look at the changes that NCrunch has made to a project in order to build, just right click on any of your projects in the Tests Window, then go to Advanced->Browse to workspace. You should be able to find the .proj file inside the generated workspace, which will have a few modifications. Just open this in your favourite text editor to see what NCrunch has done to the file. It should also be possible to build the file yourself using a command-line MSBuild action if you want to tinker with it (although you will need to reset the engine if you make changes to the file).
