Problems with DeploymentItem attribute

Question

I'm currently maintaining an "old" system written in C#.net, removing some obsolete features and doing some refactoring. Thanks god, the previous guy wrote some unit tests (MSTests). I quite comfortable with JUnit tests, but didn't do yet much with MSTests.

The test methods have a DeploymentItem attribute, specifying a text file which is parsed by the business logic method that is being tested and a 2nd DeploymentItem where just a path has been specified containing a bunch of TIF files that have to be deployed too.

[TestMethod()]
[DeploymentItem(@"files\valid\valid_entries.txt")]
[DeploymentItem(@"files\tif\")]
public void ExistsTifTest()
{
   ...
}

The tests worked before, but now I had to change the names of the TIF files contained in the \files\tif directory. According to a rule, the TIF filenames have to match a certain pattern which is also checked by the ExistsTifTest() method. Now I had to change the filenames in order to adapt them to the new requirements and suddently the TIF files are no more being deployed as before.

Can someone give me a hint why this happens or what may be the cause? The same thing happens also if I add a new text-file say "my2ndTest.txt" beside the "valid_entries.txt" in the \files\valid\ directory with the according DeploymentItem attribute on the test method. The file doesn't get deployed?

I got the images now deployed by defining the deployment path directly in the testrunconfig, but I'd like to understand why these things happen or why for instance my new file "my2ndTest.txt" doesn't get deployed while the others do.

Answer 1

In VS2010, my Local.testsettings had the "Enable Deployment" unchecked and the DeploymentItem attribute was not working. I checked it and everything worked fine. I hope this helps!

Answer 2

We have spent a lot of time by Deployment items problem to solve it in local unittest run and teamcity unittest reun as well. It is not easy.

Very good tool to debug this issue is ProcessExplorer. Using process explorer, you can check where is Visual Studio searching for the deployment items and make the correction to the project. Just filter all file operation where path contains your deploymentitem filename and you will see it.

Answer 3

I have also faced similar problems. I have all the steps mentioned above but still no luck. I am using VS2010. Then i have found that $Menu > Test > Select Active Test Setting > Trace and Test impact was selected. It started working after i change Trace and test impact to Local. This page contains very resourceful information about copying files to test results folder, I feel to add this experience as well.

Answer 4

Don't use DeploymentItem.

It is very hard to set up correctly and it was not working with my ReSharper test runner nor the native one for MSTEST in Visual Studio 2017.

Instead, right click your data file, and select properties. Select Copy to output directory: Always.

Now in your test, do this. The directory is simply the directory of the file relative to the test project. Easy.

    [TestMethod()]
    public void ParseProductsTest()
    {
        // Arrange
        var file = @"Features\Products\Files\Workbook_2017.xlsx";
        var fileStream = File.Open(file, FileMode.Open);
        // etc.
    }

Caveat. I have no idea if this works well with automated build and test systems. I'm not there yet.

Answer 5

For those who prefer to avoid the mess of DeploymentItem and take the approach suggested by @Martin Peck (accepted answer), you can use the following code to access the contents of the embedded resource:

public string GetEmbeddedResource(string fullyQulifiedResourceName)
{
    var assembly = Assembly.GetExecutingAssembly();
    // NOTE resourceName is of the format "Namespace.Class.File.extension";

    using (Stream stream = assembly.GetManifestResourceStream(fullyQulifiedResourceName))
    using (StreamReader reader = new StreamReader(stream))
    {
        string result = reader.ReadToEnd();
    }
}

For details, see this SO Thread

Answer 6

My big "gotcha" was the way DeploymentItem handles directories. I was using the two-parameter version with both as directory path containing subdirectories I wanted deployed. I didn't realize initially that it only copies the stuff in the ROOT of the directory and not the entire recursive folder structure!

I basically had [DeploymentItem(@"Foo\", @"Foo\")] and was expecting it to deploy my Foo\Bar. I specifically had to change it to [DeploymentItem(@"Foo\Bar\", @"Foo\Bar\")] and now it works like a charm.