views:

162

answers:

2

Problem: SQLite assembly referenced in my DAL assembly does not get copied to the output folder when doing unit tests (Copy local is set to true).

I am working on a .Net 3.5 app in VS2008, with NHibernate & SQLite in my DAL. Data access is exposed through the IRepository interface (repository factory) to other layers, so there is no need to reference NHibernate or the System.Data.SQLite assemblies in other layers.

For unit testing, there is a public factory method (also in my DAL) which creates an in-memory SQLite session and creates a new IRepository implementation. This is also done to avoid have a shared SQLite in-memory config for all assemblies which need it, and to avoid referencing those DAL internal assemblies.

The problem is when I run unit tests which reside a separate project - if I don't add System.Data.SQLite as a reference to the unit test project, it doesn't get copied to the TestResults...\Out folder (although this project references my DAL project, which references System.Data.SQLite, which has its Copy local property set to true), so the tests fail while NHibernate is being configured. If I add the reference to my testing project, then it does get copied and unit tests work.

What am I doing wrong?

[Update]

It seems I've found the answer here: http://stackoverflow.com/questions/851960/tfs-unittesting-not-deploying-local-copy-assembly-to-test-dir-when-on-build-serve. If I add a reference to that type in some static method in my DAL, it will get copied automatically when I reference the DAL assembly in my tests. This does seem like a hack but IMHO is a cleaner solution than having a separate script since it creates a "real" dependency.

It seems that it also gets copied if I add the SQLite assembly as an additional deployment item to my test run configuration (LocalTestRun.testrunconfig file).

Thanks for your quick answers!

+3  A: 

Your DAL project references the System.Data.SQLite assembly but this doesn't mean it will get copied to the output folder of the test project especially if it is loaded using reflection by NHibernate. Chances are if you look at the compiled DAL assembly with reflector it doesn't even have it in the referenced assemblies list as it is not used directly by the code. You've already found the solution by referencing it to the unit test project.

Darin Dimitrov
Or you could add it to your Nant-or-equivalent build script to copy over the required assemblies as a pre-test step.
Gishu
Thanks, but I'd actually like to avoid referencing a specific data assembly in my business layer tests, it just doesn't feel right.
Groo
I wouldn't worry too much about what assemblies the unit tests reference.
Darin Dimitrov
@Darin: If the referenced assembly is not included in the compiled DAL assembly, then any assemblies that reference DAL will not get this assembly included in their output folders, so this is not restricted to unit testing only. This may only be a minor annoyance, since I can easily copy all assemblies to a single target folder, but of all ways to fix this problem referencing this assembly in a project which doesn't interact with it doesn't seem as the cleanest solution. It just seems like it should be DALs responsibility to assure this.
Groo
+1  A: 

You could use the Post-build step to copy the dll to your output folder manually.

Robert Massa