DeploymentItem behaving differently in VS2010 and VS2012

Question

I have a VS2010 solution that I'm trying to upgrade to VS2012.

I'm having a problem with the MSTest unit tests in VS2012. All of the tests include DeploymentItem attributes on the test class.

[TestClass]
[DeploymentItem(@"SubDir\SubDir2\models", "models")]
public class UnitTests
{ ... }

In 2010, it's correctly copying dependent files from the SolutionDirectory\SubDir\SubDir2\models directory.

In 2012, it's attempting to copy from the directory where the tests are deployed SolutionDirectory\UnitTests\bin\debug\SubDir\SubDir2\models

I'm looking for a way to restore the old behavior.

Sommelier

Answer 1

If you create a test settings file in your solution, enable deployment in it (by default deployment is off in the test settings) and select it in the test explorer (Test -> Test Settings -> Select test settings file), then it should work without changing the code as well.

Joinder

Worked for me :) VS 2010 project to VS 2012, wasnt copying my testdata over till i did this. – Overtime

Answer 2

After installing vs2012 and .net 4.5, looks like the deploymentitemattribute is out of sync with where it moves the files and where the executable looks for the files during execution of tests.

Cheap workaround:

1. Leave the deploymentitemattribute path as-is
2. See where the file is being moved to
3. Change the test code to look in that location

Before this upgrade mstest was smart enough to find deployment items even if they were moved to a sub directory in the bin directory. Seems this is no longer the case.

So before the upgrade a line of your unit test code might look like this...

FileInfo fi = new FileInfo("temp.txt");

After the upgrade a line of your unit test code might look like this...

FileInfo fi = new FileInfo("\SubDir\SubDir2\models\temp.txt");

Pirouette

I see what you're saying. Unfortunately, the tests that I were trying to restore were more "integration" than "unit tests", and the path to the binary was hard coded elsewhere. My "cheap workaround" involved making links to the files in the project and setting them to copy on build, then I modified my "DeploymentItem" attribute to copy from the build directory. Works, but doesn't address the larger issue. – Sommelier