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 ?

These "common directories" can they not exist in a known relative path to all the other resources (i.e. in the source tree)? That is how I do it. If a build is supposed to be able to checkout/build/test without external artefacts then you have to keep native dependencies in the source tree. — Anders Forsgren, Jun 20 '12 at 09:07
Unfortunately that won't work. One of the reasons is that we use TeamCity for building. TC decides where to check out the source tree. — Oyvind, Jun 20 '12 at 09:13
I don't understand, it can't matter where you checkout the source tree? If the dependencies are all inside the source tree, and the deploymentitems are all using relative paths, what happens? — Anders Forsgren, Jun 20 '12 at 09:34
In the case of TeamCity: TC creates a new checkout directory, and the directory name is generated under the build agents work directory. For example: D:\TeamCity\buildAgent\work\1cadee32327408f3\ Therefore, there is no way of knowing where the dlls is. The reason for TC to do this is probably version handlings and things like that. There are also other reasons for deploying from a common directory and not the source tree; other developers here just fetches the latest builds from a common repository. — Oyvind, Jun 20 '12 at 09:44
Yes, if you want to fetch dlls from a repository outside the source dir then you will get problems with TC creating temp work directories. But I am only talking about relative references to dll:s INSIDE the source tree, i.e. also then inside the TC created work dir. — Anders Forsgren, Jun 20 '12 at 10:15
Ahh.. sorry, I get it. How do you maintain the dependencies in the source tree, pre-build step or similiar ? Also, what about debug/release scenarios ? — Oyvind, Jun 20 '12 at 10:24
See an edit I made in my answer regarding conditional references. — Anders Forsgren, Jun 20 '12 at 10:35

score 2 · Accepted Answer · answered Jun 20 '12 at 12:45

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

I don't like the idea of keeping binaries within the source tree
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

added a new subfolder in the test-project, say "NativeDlls"
added the needed dlls as links into the NativeDlls folder
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.

Anders Forsgren · Answer 2 · 2012-06-20T10:31:34.077

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.

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

2 Answers2