Edited
So, on VS 2017 Community edition, I decided to try and do a simple test to replicate what you were seeing, and I did. Running it from the IDE, the DeploymentItem
attribute worked as expected, but not from mstest
. I would have expected that people would have seen this before if it's truly a bug, but maybe people just haven't been trying that out much with VS 2017 yet.
Anyway, what did finally work for me was to create a testsettings file with the DeploymentItem
specified there. This is the file I used:
<TestSettings name="Local" id="00ebe0c6-7b64-49c0-80a5-09796270f111" xmlns="http://microsoft.com/schemas/VisualStudio/TeamTest/2010">
<Description>These are default test settings for a local test run</Description>
<Deployment>
<DeploymentItem filename="ConnectionStrings.config"/>
</Deployment>
</TestSettings>
There's also an outputDirectory
attribute if you want to specify that. The DeploymentItem
node seems to work just like the DeploymentItem
, so the filename needs to be relative to the output directory (assuming you haven't overridden it in the testsettings file you're using; since you already have it copying your ConnectionStrings.config to the output directory, I think this could work for you. Alternately, you could just make it ..\..\ConnectionStrings.config
if you didn't want to copy it into your output folder in the build but did want it copied using mstest
.
Then just add a /testsettings:<testsettingsfilename>
to your mstest
command line execution.
Original Post
Unless I'm greatly mistaken, running mstest.exe only runs the already-built test project, and doesn't go back and build the test project (and how could it? It's a testing tool, not msbuild, and you're just pointing it at the test DLL, not the project file). So, if you are just running mstest and not ever building your project from Visual Studio or through msbuild or whatever, the changes that you've been making won't take until you do actually build your project again.
Can you verify that you've actually re-built the test project with that DeploymentItem
attribute that SMA referenced (maybe check the last time that your Tests.DLL
was updated as a quick first step), and then run your mstest
command against the newly-built Tests.DLL
? I would expect, based on my own knowledge and this answer about copying a file to mstest's test folder, that you would see your config file copied over into the test run directory, as long as that config file exists in the first place.