Search code examples
mstestdeploymentitem

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

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 ?

Solution

  • 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.