Hi Peter -

Support was added for including the copy of content files in the 1.43 release, so in theory this should work. In practice, I'm hoping you haven't been hit with a bug.

Does it make any difference if you turn on the 'Copy referenced assemblies to workspace' setting for ALL the projects in the solution, then reset the NCrunch engine?

If not, is there any chance you can put together a small reproduction of the problem? Issues such as this can sometimes be hard to pin down because of the amount of shadow copying involved.


Thanks!

Remco

Do the tests stay green now even if you restart the IDE? I'm wondering if perhaps NCrunch failed to correctly detect the content files that needed to be copied because MSBuild had already copied them with a prior build. I'll make a note to review how some of this code works to see if I can find any obvious holes. Please do let me know if you manage to create a small reproduction of the problem, or if you find clear steps to reproduce.


Cheers,

Remco

Thanks Peter!

Because of the way NCrunch's build optimisations work, the 'Copy referenced assemblies to workspace' setting is needed for any project to copy assemblies or content files from a referenced project. This is behaviour by design - I'll quickly explain why this is the case.

Let's just say you have project A containing a content file MyResource.xml. This content file is set to be copied to the bin\debug directory of the project when it is built, and we'll just assume that some internal logic in Project A makes use of it.

We also have project B, which could be a unit test project referencing project A using a ProjectReference in the usual way. Project B executes (via test) code that runs within Project A making use of MyResource.xml.

Now lets just say we make a change to the 'MyResource.xml' file in project A. Because NCrunch is reliant on build logic to recopy (or potentially reprocess?) this file, NCrunch needs to rebuild project A. If project B required this file to exist in its bin\debug directory too, then it would also need to be rebuilt. Along with any other project that referenced either project A or project B. If project A sits at the bottom of a large dependency tree of 50 other projects, each of these projects would need to be rebuilt before any tests could be run.

NCrunch has no reliable way of knowing how depending projects make use of the projects they reference, so to prevent builds from running to the moon every time a change is made, it simply avoids copying the resource files and assemblies of referenced projects into the bin\debug of referencing projects. By turning on the 'Copy referenced assemblies to workspace' setting, you effectively tell NCrunch that you need these files to be copied, and so it won't execute shortened builds and you'll notice a bigger pause before your tests kick off and run.

I try to encourage people to design their code in such a way that they don't need to switch on the 'Copy referenced assemblies to workspace' setting. In this situation above, usually this would come down to how the MyResource.xml file is located within Project A. Code often makes the assumption that resource files are located adjacent to the runtime assemblies by relying on the current directory. If you avoid this and instead use the directory of the executing assembly, you can completely avoid the issue and you won't need to turn on the 'Copy referenced assemblies to workspace' setting. i.e. Path.GetDirectoryName(typeof(ATypeInMyAssembly).Assembly.Location) + "\MyResource.xml"

But where this isn't possible, switching on the copy referenced assemblies setting for all projects in the solution will allow your build process to work more or less as normal.

If you have this setting switched on and the files aren't copying, then this is definitely a bug that I'd much like to fix!


Cheers,

Remco