The standard way to solve this is to enable the 'Copy referenced assemblies to workspace' setting for the test project, and down the dependency chain into the project containing the hibernate file. When this setting is enabled, NCrunch will copy the file in the same manner as a normal MSBuild action, eventually depositing it in the test project's bin directory.

Of course, this will have an impact on performance. So there may be a better way - it just depends upon how non-standard you want to get. Do you have any opportunity to run code before the XML file is read from the current directory? If so, it may be possible to locate the file and copy it during the test initialisation using the methods available on the NCrunch.Framework.Environment class.

Ok - Out of interest, how large is this 30s project in lines of code? And how long does it normally take for VS to build it?

Thanks, this is really useful information to help with further optimisation. The difference in static vs dynamic analysis is particularly interesting.

Your best bet is the NCrunch.Environment.GetAllAssemblyLocations method. This method will return the full file path of ALL assemblies included in the test application domain. It's possible for you to enumerate this list of files, find the output file from the project containing the NHibernate config file, then extract the directory of this file. The NHibernate config file will be in the same directory. This will be in one of the NCrunch workspaces. Give it a try inside a debugger and see if it helps.

Nope using Assembly.GetExecutingAssembly().Location didn't work out since this returns the utility assembly having this code. Using System.Environment.CurrentDirectory seems to work, but can I trust NCrunch that this is always set to the test assembly location?

'Additional files to include' is needed to specify files that NCrunch should copy to the workspace. This is basically the same as referencing them in the project file. It isn't intended to be used to specify files that should exist in the build output directory - although this is technically possible by including files that are in the bin\debug directory in the foreground solution, I generally don't recommend this because it creates a dependency on the foreground build (though sometimes this is the easiest option).



This is by design. NCrunch can have many workspaces for a single project and will create new ones when it needs to.



A cleaner option is to include the DLL files using 'Additional files to include' from their original place in your solution (i.e. nuget packages directory). You can then include a PostBuildEvent to copy the files into $(ProjectDir)$(OutDir) so that they exist in the same directory as the output file. Set a condition on the PostBuildEvent so that it will only run under NCrunch - condition="$(NCrunch) == '1'". This will remove the dependency on the foreground build while still allowing the files to land in the right place.



Yes. Placing the files manually (or via PostBuildEvent) inside the output directory manually will trigger NCrunch to show these warnings, as it causes the CLR to load assemblies from places that NCrunch isn't expecting. As long as the DLLs are binary-equivalent to the files NCrunch is trying to reference, you shouldn't experience any runtime problems here.




Try to avoid touching the files inside the workspaces manually, and make sure you don't copy around output files from other projects in your solution. Generally when I've seen this error occur, its because NCrunch is loading and resolving the wrong version of user-built assembly at runtime.

No. NCrunch will not perform an auto package restore, as this tends to use a large amount of disk space (through the multiple workspaces), and as you've described, it also slows down the build. The drawback is that if you don't have the packages restored at the time you enable NCrunch, you'll need to do a VS build to restore them before the engine can work.



Most likely the workspace is still in use by a test runner process that hasn't yet been terminated. NCrunch will clean up workspaces when it identifies that they can no longer be re-used. It will also clean them up when the engine is shut down or the IDE is closed.

I think this is a design oversight. It should be possible for NCrunch to build a solution on a fresh checkout from VCS on the build server. I'll make a note to see if there is a way this can be improved. Thanks for making me aware of it.

Thanks for feedback. Yeah nuget package issue is easily solvable by running nuget restore before starting the build via NCrunch.

(and I seem to require to build it via msbuild anyhow before invoking NCrunch so I can utilize the "copy dll from project output folder" since I can't solve the "MethodNotFound" exception when copying log4net.dll manually.)