MSTest: A sensible way to deploy items from a common directory?

Question

I have lost a few hairs when trying to deal with DeploymentItem recently.

We have a few common directories for native dll's, and many tests depends on these.

For C++ projects, we use propertypages, where these paths are defined. These can even be imported in a C# project aswell, with some manual editing (as they are MSBuild files). Still I can't figure out how to utilize them in tests.

Unfortunately, the DeploymentItemAttribute can't use the properties in the sheet, but it can utilize environment variables. I was hoping to avoid forcing everybody to define global environment variables...

I have seen various suggestions around the net, but haven't really found a simple solution.

Anybody have good approach to this ?

Answer 1

Anders' answer is a good solution, but in my case:

1. I don't like the idea of keeping binaries within the source tree
2. Many dlls dont have specific versions, and they are updated on regular basis.

I somehow ended up with this solution:

First, I included the global VC++ property page into the test project. This must be done manually by adding this directive under the <Project> tag on top of the .csproj:

<Import Project="$(UserProfile)\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props" />

I now got access to the properties/macros that defines the dll paths in my C++ environment.

I then

1. added a new subfolder in the test-project, say "NativeDlls"
2. added the needed dlls as links into the NativeDlls folder
3. the links are absolute, but can be replaced with macros from the property sheet included above:

<Content Include="$(MyLibLocation)\GDAL18BIN\gdal18.dll">

<Link>NativeDlls\mylib.dll</Link>

<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>

</Content>

The dlls is then ready to deploy:

[TestMethod]
[DeploymentItem(@"NativeDlls")]
public void TestSomeStuff()
{
}

And, as Anders mentions: The remaining work is to set debug/release and 32/64 conditions.

Answer 2

If these are external dependencies used only by this project (not shared between source trees) then I suggest moving them into the source control. Dependencies should be versioned together with the source. The rationale being that you should be able to check out a revision of the source tree (any revision in the history), and it should build. If you have binary dependencies that are not under source control, you will have problems knowing which version of the dependency you need when you build a specific version of the source.

If you can move the dependencies into the source tree (e.g. $svnroot/trunk/dependencies) then you can use test deployment with only relative paths. It will work under TeamCity as well as on any developer machine.

If you cannot version your dependencies or you must have them outside the repository for some other reason, then you can use an environment variable that the test deployment can use. See This msdn post for an example

EDIT: moved a comment about managing binary dependencies here

For csprojs I just have a dll-reference in the projects to the dll:s in the lib directory under the source tree (i.e. reference to ..\lib\log4net.dll). If you want to reference separate libs for separate builds, e.g. different for x86/64 or Debug/Release, then VS doesn't support it but MsBuild and the csproj file does, so you can add conditional references but you have to edit the csproj by hand to include for example the x86 dependency only if platform is x86 and so on.