Problems with DeploymentItem attribute

Question

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

The test methods have a DeploymentItem attribute, specifying a text file which is parsed by the method with business logic 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.

Joanne

A big gotcha here is to realize that all of the items specified in the DeploymentItemAttribute will be copied to the location where your test assemblies run from. In other words, if you were hoping that it would preserve your directory structure you will be out of luck. If you need it copied to a specific directory, then use the two parameter DeploymentItem(source, outputDir) version. FYI - you can go old school to find out where the files are run for MsTest by dropping in a System.Console.WriteLine(System.Environment.CurrentDirectory) into one of your tests. NCrunch didn't have this problem! – Holograph

Answer 1

DeploymentItem is a bit of a mess.

Each file in your solution will have a "Copy To Output Folder" setting in VS.NET. You need this to be "Copy Always" (or similar) in order to get the files into the output folder.

Check that you've got this set for the new files. If you don't have this set then the files won't get copied to the output folder, and then they can't be deployed from the output folder to the folder where MSTest does it stuff.

Personally, if I have files that I need for my unit tests I've found that embedding those files as resources into an assembly, and having that assembly "unpack" itself during the tests is a more predictable way of doing things. YMMV.

note: These comments are based upon my experience with VS2010. Comments to my answer would suggest that this is not problem with VS2012. I still stand by comments that using embedded resources involves less "magic" and, for me, makes the "arrange" stage of my unit tests much more explicit.

Faenza

That was exactly the issue. You're right, these DeploymentItems are a bit messy. Thanks a lot. – Joanne

Copy To Output Directory never affects how MSTest deploys files. This answer is incorrect. – Irruptive

On VS2010 Premium, making this change (and no other change) caused the file to deploy. Thus, I conclude based upon actual evidence that it DOES affect MsTest deployment. – Enterectomy

Agreed. I've seen this single change turn DeploymentItem frowns upside down. – Faenza

On VS2010 Premium, be sure to check the answer below about enabling Deployment for the Test Settings. However, I still can't get DeploymentItem to work as advertised. Only the Copy To Output Directory setting seems to be reliable for both MSTest and Resharper tests. – Mammiemammiferous

kzu is spot on, all you need to do is provide the right path. If the path is relative, Visual Studio will use $(SolutionDir) as its base. – Uncork

This appears to no longer be required on VS2012. My deployment items are being deployed with "Copy To Output Folder" set to "Do Not Copy". – Valverde

Thanks @Mike. I'll update my answer to specify that it relates to VS2010 – Faenza

It's great how DeploymentItem gives you no notice when it is unable to copy the single file you've provided it. – Diatomic

@Irruptive - That's incorrect, it does make a difference in VS2010. – Banquet

You have to add the directory of the testfiles explicitly in the .testsettings file and set deploy enabled, otherwise no files are copied. – Pali

I got it finally working in VS2013. I had to set the Local.Testsettings, and set the path relative to the .sln file (NOT the test project). – Replenish

Wow! The solution works 10 years later in VS2017 :). – Fornicate

Using Visual Studio 2019. "Copy if newer" fixed it. I hate "Copy always" because it forces the project to rebuild on a lot of scenarios like debug or incremental build. – Wane

Answer 2

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!

Elias

I've been banging my head against a brick wall for ages trying to get it to work.... thankyou! – Intra

I think it would have been nice if the framework issued a warning that DeploymentItem attributes are being ignored if this setting is turned off. I also put a nice concave impression into my desk. – Mammiemammiferous

Note that Local.testsettings is in Solution Items – Peruke

I also had to add the directory containing the items I wanted to deploy into Local.testsettings also: i.imgur.com/p1z3m9R.png – Peruke

Using VS2017 in 2018 checking the 'Enable Deployment' is still the solution for this issue. And sadly still now warning from Visual Studio whatsoever. So thanks for this solution. – Verbosity

Can you improve your answer to mention where exactly can people check "Enable Deployment"? I can't seem to find it in VS2022... unless they removed it? – Triennium

Answer 3

I have also faced similar problems but i found easy 3 step solution for this:

Assuming your folder structure looks like this: SolutionFolder\ TestProjectFolder\ SubFolder\

1. Go to "Solutions Items/Local.testsettings" > "Deployment" > Check "Enable Deployment"
2. If you are using VS2010, make sure any files you want to deploy have their "Copy To Output Folder" property set to "Copy Always" or "Copy if Newer"
3. Attribute your TestMethod with either one of:
   • [DeploymentItem(@"TestProjectFolder\SubFolder")] to deploy all contents of <SubFolder> to the Test Run directory
   • [DeploymentItem(@"TestProjectFolder\SubFolder", "TargetFolder")] to deploy all contents of <SubFolder> to <TargetFolder> in the Test Run directory

One final note about MSTest (at least for VS2010):

If you want the <TargetFolder> to have the same name as the <SubFolder>, using [DeploymentItem(@"SubFolder", @"SubFolder")] will fail silently as the MSTest runner hits a silly edge case. This is why you should prefix the <SubFolder> with the <TestProjectFolder> as so: [DeploymentItem(@"TestProjectFolder\SubFolder", @"SubFolder")]

Shrubbery

The note about the SubFolder naming failure is a gem. – Emissivity

VS 2015 seems to be a little different. I needed to remove the "TestPojectFolder" part in the DeploymentItem Attribute. – Fimbria

Answer 4

For hopefully helping someone else out: I tried all the suggestions here and still my deployment item was not being copied.

What I had to do (as suggested here) was to add a second parameter to the DeploymentItem attribute:

[DeploymentItem(@"UnitTestData\TestData.xml", "UnitTestData")]

Todhunter

Answer 5

If you go into your .testrunconfig file and under deployment uncheck "Enable Deployment", the tests will run in their normal location, and everything will work like it does when running the app outside a unit test.

Besought

Had some issues with this as well. As a PM I do not have access to all tools used by dev. In this case ReSharper copied the file correctly while MSTest failed to do so. --> I experienced errors while dev was OK. Change to 'Test-> Edit Test Settings -> Local settings -> Deployment' including the file in question fixed this for my MSTest use. – Langlauf

Answer 6

This probably doesn't relate to your exact problem, but here's a couple of tips I found with the [DeploymentItem] attribute.

1. Copy to output directory should be set to Copy Always.

It does NOT work when used with the [TestInitialize] attribute

[TestInitialize]
[DeploymentItem("test.xlsx")]
public void Setup()
{

It should be on your [TestMethod], e.g.

    [TestInitialize]
    public void Setup()
    {
        string spreadsheet = Path.GetFullPath("test.xlsx");
        Assert.IsTrue(File.Exists(spreadsheet));
        ...
    }

    [TestMethod]
    [DeploymentItem("test.xlsx")]
    public void ExcelQuestionParser_Reads_XmlElements()
    {
        ...
    }

Ingeborgingelbert

This is an insanely annoying limitation. I feel like for many cases, the time to deploy should be in Initialize. What if all my tests use the same supporting artifacts? I guess I'm supposed to copy and paste decorators across dozens of test methods? Ridiculous. – Yep

You can also put the [DeploymentItem] attribute on the class – Peril

Answer 7

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\ParseProducts\Files\ParseProducts_Workbook_2017.xlsx";
        var fileStream = File.Open(file, FileMode.Open);
        // etc.
    }

This does seem to work well with automated build and test systems.

Here is a picture of where the files go in the solution:

Aga

Well no, it is relative to the bin/Debug-directory right? – Bibb

@Bibb in the solution the test file is relative to the project. When the test is run, things are copied to bin/Debug. – Aga

"Don't use DeploymentItem" seems kinda harsh. I love it, works right when it's setup correctly. I'd say use it if you need it. – Featurelength

Answer 8

After trying all of the other suggestions listed here I still couldn't figure out what was going on. Finally I discovered that there was no settings file selected under Test/Test Settings menu, which meant that Deployment wasn't being enabled. I clicked the Test/Test Settings/Select Test Settings File menu item, selected the Local.TestSettings file, then everything worked.

Valverde

Answer 9

Not sure if this exactly answers the question, but it may help some. First, I've found the "Enable Deployment" box must be checked for deployment to work. Second, the doc says the source path is "relative to the project path" which at first I took to mean the project folder. In fact, it seems to refer to the build output folder. So if I have a project folder called 'TestFiles' and a file in it called Testdata.xml, using the attribute this way doesn't work:

[DeploymentItem(@"TestFiles\Testdata.xml")] 

I can mark the Testdata.xml file Copy Always, so that the build puts a copy under the output folder (e.g., Debug\TestFiles\TestData.xml). The deployment mechanism will then find the copy of the file located at that path (TestFiles\Testdata.xml) relative to the build output. Or, I can set the attribute this way:

[DeploymentItem(@"..\\..\TestFiles\Testdata.xml")] 

and the deployment mechanism will find the original file. So either works, but I have noticed that using the Copy Always I occasionally run into the same problem I have when editing the app.config file in a project - if I don't change code or force a rebuild, nothing triggers copying of files marked to be copied on build.

Maun

The relative path was the issue for me and this fixed it. I added 2 sets of DeploymentItem statements depending on how the tests were run. – Aborticide

Answer 10

I had Deployment flag disabled first. But even after I enabled it, for some unknown reason nothing even target DLLs would still be copied. Accidentally I opened Test Run window and killed all the previous runs and magically I found all the DLLs and files I needed in the test folder the very next run... Very confusing.

Langur

Answer 11

I was having huge problems trying to get files to deploy - trying all the suggestions above.

Then I closed VS2010; restarted it, loaded the solution and everything worked. (!)

I did some checking; After setting the 'Enable deployment' flag on local.TestSetting you should not simply re-run the test from the Test Results window. You have to get the previous test run removed from the UI e.g. by running a different test, or by re-opening your solution.

Expeller

Answer 12

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

Woodring

I've had problems with Assembly.GetExecutingAssembly() when running on a build server -> it would return the test runner instead of the actual test assembly. Getting the assembly by reflecting it off a fixed type in the testassembly (for example your testclass) solved this for me. – Felicio

Answer 13

Since I always found the DeploymentItem attribute a mess, I do the deployment of such files by using the post-build script. - Make sure the files you wanna copy has the Copy Always property set. - Modify your test project post-build script to copy the files from build target folder(Bin\Debug) to the location where your test is expecting them.

Fennec

Answer 14

Try this for VS2010. So you do not need to add DeployItems for every tif
Remove the

[DeploymentItem(@"files\valid\valid_entries.txt")]  
[DeploymentItem(@"files\tif\")]  

Add a test configuration.
- right-click on solution node in solution explorer
- Add -> New Item...
- Select Test Settings node on the left, select the item on the right
- Click Add

Call it eg TDD

Choose TDD under TestMenu > Edit Testsettings.

Click on the Deployment. Enable it and then Add the files and directories that you want.There will be a path relative to the solution. The files will be put on. The original file are for example here:

D:\Users\Patrik\Documents\Visual Studio 2010\Projects\DCArrDate\WebMVCDCArrDate\Trunk\WebMVCDCArrDate\Authority.xml  

When I run my unit test it gets copied to

D:\Users\Patrik\Documents\Visual Studio 2010\Projects\DCArrDate\WebMVCDCArrDate\Trunk\WebMVCDCArrDate.Tests\bin\Debug\TestResults\Patrik_HERKULES 2011-12-17 18_03_27\Authority.xml  

in testcode I call it from:

[TestMethod()]
public void Read_AuthorityFiles_And_ParseXML_To_Make_Dictonary()  
{  
  string authorityFile = "Authority.xml";  
  var Xmldoc = XDocument.Load(authorityFile);  

There is no need to choose Copy Always; put the files in the testproject; add hardcoded paths in the testcode. For me this solution worked best. I tried with DeploymentItem, copy always but it was not to my liking.

Airscrew

Answer 15

I've been working on this in VS2013. My findings to get this working:

• Copy to output directory should be set to Copy if Newer / Copy Always: MANDATORY.
• "Enable Deployment" in .TestSettings: NOT REQUIRED. I got this working without a .TestSettings file at all.
• Specifying a folder as 2nd parameter: OPTIONAL. Shapes the output folder layout, works fine without.
• SPACES in the filename: this caused me a headache - the file was never copied. Removing the spaces fixed this. Haven't looked into escape characters yet.

A tip I also learned the hard way: do not forget to add this attribute to each individual test. The file copies on the first attributed test in the testrun, but remained missing when the order of the tests changed and non-attributed tests tried to find the file first.

Felicio

Tried everything here before getting to your answer which was the very last one. The culprit: SPACES IN THE FILENAME! Good callout. – Ronaldronalda

Using Visual Studio 2019. "Copy if newer" fixed it. I hate "Copy always" because it forces the project to rebuild on a lot of scenarios like debug or incremental build. – Wane

Agreed. I have updated my answer to include Copy if Newer. – Felicio

Answer 16

For me, the root cause was something else entirely: The production code being exercised by my tests was renaming and/or deleting the .xml test file being deployed.

Therefore, when I would run my tests individually, they'd pass, but when running them all together, the 2nd and subsequent test would fail with "file not found" errors (which I'd originally misdiagnosed as the DeploymentItem attribute not working).

My solution was to have each individual test method make a copy of the deployed file (using this technique), and then have the production code being tested use the copied file instead of the original.

Ramage

Answer 17

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.

Bramwell

I know this is a very old answer, but if you are able to elaborate on how you use ProcessExplorer, that would be helpful. I'm not seeing how to view file operations at all, much less filter them... – Putnam

Answer 18

Besides the Deployment attribute needing to be checked, I discovered something else about the DeploymentItem attribute.

[TestMethod()]
[DeploymentItem("folder\subfolder\deploymentFile.txt")]
public void TestMethod1()
{
   ...
}

Your deploymentFile.txt needs to be relative to the solution file and not the testfile.cs.

Vilayet

I finally got this working by having my DeploymentItem source be relative to the test project. So I have a project in my solution, "Service.Tests". Under there I have a folder "FilesForTests" which has the files I want to copy. I used [DeploymentItem(@"FilesForTests\MyFile.txt", "FilesForTests")]. I think we are saying the same thing? – Putnam

Answer 19

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.

Electroencephalograph

Answer 20

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.

Phototelegraphy