I'm using Sqlite to try to setup my integration tests to use an in-memory DB. I have a TestHelpers assembly that references Sqlite (installed with Nuget), and which uses Autofac to resolve my DAL. I have many test projects that reference the TestHelpers project. Whenever I try to run an integration test that exercises the code that resolves my DAL, I get the following exception:

System.Reflection.TargetInvocationException : Exception has been thrown by the target of an invocation.
----> System.DllNotFoundException : Unable to load DLL 'SQLite.Interop.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

If I manually copy this file into the workspace bin directory of my tests, then this exception goes away.

I've attempted to resolve this problem by adding this file to the General->Additional files to include setting, but this doesn't seem to be doing anything. If I check the workspace directory, SQLite.Interop.dll still isn't there. This isn't optimal anyways, because I don't want to have to include this file as an "Additional file to include" in every test project. I tried doing this for the TestHelpers project, but that doesn't seem to do anything either. The only assembly that ends up in my workspace bin directory is my specific test assembly.

The only solution to this that I've found is to include the SQLite.Interop.dll assembly in the TestHelpers project as content, set it to copy only, then change the integration test Build Settings->Copy referenced assemblies to workspace. This will put all necessary file into the test's bin workspace bin directory so that it can be found, as well as every other referenced assembly, "at the expense of build performance". And I will have to manually do this for every test project, which I don't want to have to do.

So the question is.... Is there any better way to do this? Why isn't the "Additional files to include" setting working to do what I want?

Well, this particular assembly is a strange beast. It's an unmanaged assembly, so I'm not sure that it even can be referenced. SQLite has a special build target that will copy this assembly into a sub-directory in the bin directory of the project (actually, it does this twice, once for x86 and once for x64). I'm not even entirely sure how this is supposed to be handled. There seems to be a lot of confusion around it. One may have to manually copy/move the .dll into the bin root in order for it to be found and used. That's the reason that I included it as 'content' in my TestHelpers project, and set it to copy always.

But I guess the bottom line is that all of my individual test projects will have to 'Copy referenced assemblies' (and only if they happen to be integration tests, which are the only ones that will be using this feature). The only reason I don't like this solution is that it's opaque. Since this is a per-user setting, I can imagine people on my team running into this over and over, and having to re-discover the solution. Intuitively, referencing the TestHelpers project is the only thing that one should have to do in order to be able to use its capabilities. In my experience, trying to document something like this is useless, as the documentation is never found and usually never even checked.

So is there any better way to make this as transparent as possible?

SQLite (via Nuget) recently changed their native file deployment. They used to add the native files to the csproj file as content that was copied when newer. However, it appears that their current package copies the files as part of the Nuget dependency verification step during compilation. This makes it hard for NCrunch as NCrunch only copies files it sees as relevant to the csproj to a temp folder.

I was able to work around this issue using the "Additional files to include". It required that I manually compile the project at least once after getting the Nuget package. I added a path that looks like this:
bin\*\x*\*.dll

Perhaps NCrunch could run some nuget validation command for a project file as part of its build?