Hi,

Thanks for posting and sharing this issue.

I believe this issue should be easy to resolve by adding the sqlite3.dll file to the Additional files to include setting. This will inform NCrunch of the dependency on the file so that it can copy it to the workspace, allowing your build to function normally (see Implicit file dependencies for more information on this).

Because NCrunch performs background build and execution tasks, the shadowing is unfortunately necessary for about 90% of the features in the product. There is no way to build and run tests reliably against a project as it exists in its original location on disk, as there is simply too much interference from Visual Studio and other processes to allow this to happen. To rely on foreground solution test running is basically the same as going back to manual test runs with a code coverage tool, which would sadly defeat the purpose of the product.

I definitely recommend having a read of the 'Considerations and Constraints' section of the documentation. I realise that many of these constraints will likely feel artificial when working with an existing solution that hasn't been designed with them in mind, but being aware of them may help save you from much frustration.

Cheers,

Remco

If the Additional Files To Include configuration setting doesn't meet your needs, another option that may be worth trying in your situation is to include a reference from the project XML file to the DLL file being referenced. You can do this simply with a 'None' XML element, for example:
<ItemGroup>
<None Include="$(SolutionDir)Library\Sqllite3\Sqllite3.dll" />
</ItemGroup>

NCrunch will then detect the file as being used by the project and will copy it, allowing your build to function as normal in the NCrunch workspace.

I realise that what you are asking for is effectively for me to provide you with a feature set that will allow NCrunch to work without any configuration required, but I'm afraid that with the current design of the tool this is simply impossible. The features provided by NCrunch bring with them an inherent compatibility penalty that can affect solutions that haven't been designed with the tool in mind. It's almost always possible to get the tool to work with a solution, but the effort involved in this is always variable and depends upon the situation.

The simplification of NCrunch configuration and resolution of compatibility issues is an ongoing exercise that so far as seen many years of effort behind it. There will also be many more years further spent continuing to evolve the tool to make it as easy to 'switch on' as possible. Believe me, there is plenty of incentive to continue to make these improvements as supporting the environments that NCrunch operates in is an expensive and time consuming exercise. The current model has had considerable thought put behind it along with several years of trial and error. It may not always seem like the easiest approach in every niche scenario, but it does work.

The current model of shadowing individual projects is as fundamental to the tool as the language it's written in. The work that NCrunch does needs to be carefully sandboxed with all its dependencies controlled. The sorts of issues that can appear from having references from the NCrunch workspace to the foreground solution are much more numerous and much harder to resolve than the dependency issues you're currently facing.

I agree that there are several ways of handling the identification of solution or project dependencies. The approach you've suggested also has its own caveats - for example, where would the files be copied from? The root solution directory? This would then leave out any files referenced relatively above the directory of the .sln file, which is quite a common situation. NCrunch also requires knowledge of which projects use which files, as it does in fact work at project level (not solution level), so there would need to be consistent way to identify these dependencies. The shadowing mechanism is not as simple as it might immediately seem, and there are many reasons for it existing in its current form.

I'm sorry that I can't offer you a solution that will take your frustration away and make the tool work in the simplest possible way in your environment. The areas of NCrunch that you've called into question are too fundamental to ever change, even if a better implementation can actually be found.

Thanks for your understanding. I'm not trying to shoot down your idea - I just have trouble fitting it with the current design of the product in a way that I think will achieve its desired outcome. I really do appreciate the effort you've taken to share the concept with me and I do understand that you do so with the intention of making NCrunch a better and more usable product .. which is something that I really respect and am grateful for. Though I guess as is often the case in the industry we work in, nothing is ever as simple as it seems :)