Thanks Julien! The sample solution you've provided was enormously helpful in identifying this problem.
You've managed to find a hole in NCrunch's optimised build. Basically, because the constant is evaluated at compile time and not run time, it's value is being hard-baked into the references (one in the tests project, one in the production code). By default, NCrunch will avoid rebuilding projects that depend upon changed projects unless the surface of the changed project has changed (i.e. if you've added a parameter to a public method, then referencing assemblies must be rebuilt). This has many advantages, as when changing the contents of a method at the bottom of a huge dependency tree of assemblies, the entire dependency tree doesn't need to be rebuilt. In this case, NCrunch isn't recognising that the new constant value requires a rebuild of the dependent Tests assembly, so it builds the test domain with an older version of the assembly and the string constants clash.
I've noted this down to be fixed in the next maintenance release. If you're making frequent changes to string constants that are referenced across assemblies, it may be worth turning on the
Copy referenced assemblies to workspace setting for all projects involved - as this will turn off NCrunch's optimised build and resolve the issue entirely. However, because the optimised build adds considerable value, I would probably recommend just resetting the engine if you change one of these string constants (assuming you don't do this very often).
As far as bugs go, this was a good catch. This issue has been in place over the life of the software, and no one has bothered to report it before .. Most likely they just reset the engine.
Cheers,
Remco
