Why doesn't VS2010 copy all DLLs in /bin/debug to the unit test directory?

I have a unit test which depends on some code that uses MEF. When I run the test, MEF (I believe) MEF tries to load all dependent DLLs for all the DLLs in the unit test's executing directory.

The problem is that VS2010 for some reason isn't copying all the DLLs from the /bin/debug directory to the unit test's executing directory, and I don't know开发者_如何学JAVA why. Here's an example:

Unit test is complaining is can't load assembly A, so I include project B which assembly A has as a dependency. In the /bin/debug folder for the unit test project, all the DLLs are in there, but when I look at the unit test's executing directory, assembly A isn't there.

I could start adding DLLs as refs to the unit test project one by one, but I feel like I should have to.

Thoughts?

thanks, Mark

Maybe the DeploymentItem attribute can help, http://msdn.microsoft.com/en-us/library/ms182475.aspx:

For the parameter of the DeploymentItem attribute, specify the folder or file that you want to deploy for this test. You can use either an absolute path or a relative path. Relative paths are relative to the RelativePathRoot setting found in the .testrunconfig file.

[TestMethod]
[DeploymentItem("MyTestProject\\testdatasource.mdb")]
public void TestMethod1()
{

// TODO: Add test logic here

}

You can add the project as a reference and it will sort it out. Right click add ref project tab.

Dont ref the dll itself in teh bin\debug folder.

As test projects are simply extensions of the production code, it's not uncommon to share the same dependencies. In some cases, excluding a dependency may compile fine but will fail when the code under test tries to load a missing dependency at runtime (as you've discovered). If your tests however have to use a dependency in the test code, you'll find that you won't be able to compile without referencing that dependency.

Also keep in mind that when you execute a TestRun with MSTest, it's not the compilation process that copies the assemblies -- there's a post compilation step that copies the dependencies for the tests to a specialized "test run" folder, typically under TestResults. Visual Studio supports a feature called "Test Deployment" that can copy additional test data, etc to the test run.

The other element at play here may be the dynamic composition nature of MEF. One of the key benefits of MEF is that it follows a plugin model that dynamically loads assemblies into your application at runtime: simply drop in new assemblies and MEF will pick them up. As such, it's common that the design of the main application will not have direct references to these dynamically loaded assemblies. If you're using MEF in your tests to dynamically load tests, these tests must be copied (using Test Deployment) or referenced as part of the test project.