Problems with MSTest.exe

I’m having problems using MSTest from the command line to execute tests on my build server. I have a VS2005 (Beta 2) solution set up as follows (actual names changed for clarity):< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

C:\MyProject [solution root]

C:\MyProject\MyProject [production project]

C:\MyProject\MyProjectTests [test project]

When I run MSTest from the command line (executed from “c:\MyProject”):

[path to mstest.exe folder]\mstest.exe /testcontainer:"MyProjectTests\bin\MyProjectTests.dll" /runconfig:localtestrun.testrunconfig

I get the following error in my output (which I never see executing tests from within the VS IDE):

Conflict during test run deployment: deployment item 'C:\MyProject\MyProjectTests\bin\MyProject.DLL' cannot be deployed to 'MyProject.DLL' because otherwise it would overwrite deployment item 'C:\MyProject\MyProject\bin\MyProject.dll'.

As you can see, MSTest is trying to deploy this file twice. If I have my account logged onto the machine, this does not cause the test run to fail. But if the account is NOT logged on, and this runs as a scheduled task, then I get the additional error:

Access is denied.

And all the tests abort and do not even run.

Any help here

Thanks.

Answer this question

Problems with MSTest.exe

Shirley
Can I make another official request for the ability to DISABLE DEPLOYMENT altogether I have my build server and automated test environment set up and I see no need whatsoever for deployment for anything that we're doing. I would LOVE to be able to execute test projects from their bin folder.

Please...
phantastikfan
Hi Michael,

I also have similar error (warning messages, which apply to all dlls that my tested projects depends on.

For e.g.

Conflict during test run deployment: deployment item 'C:\Projects\MyProject\bin\Debug\MyProject.dll' cannot be deployed to 'MyProject.dll' because otherwise it would overwrite deployment item 'C:\Projects\MyProject\bin\Release\MyProject.dll'.

As you can see it tries to deploy debug version and override release version. I've only just stared with using UnitTests and don't fully understand what is behind this deployment mechanism.

You say this is a warning only and the test should run but I don't have any other error except the above one for each .dll , .exe and .pdb file.

BTW. I'm trying to run the test from VS 2005.

Ewa
PETER I
Ewa,

Somehow you test solution refers to items from both Debug and Release folders. I would like to understand where deployment items come from. Are you using deployment items in Test Run Configuration Are you using DeploymentItem attribute or per test deployment items When you run tests, what is your build configuration: debug or release

In general our deployment uses priorities for deployment items: if there is a conflict, the item with higher priority wins. The priorities are explained here: http://msdn2.microsoft.com/en-us/ms182475.aspx, look for Deployment order.

Thank you,
Michael Koltachev
Visual Studio Team Test
project_tek
Can you please make that scheduled task user an administrator temporarily and see what happens We are considering execution without deployment for next version.

Thank you,
Michael
metalozavr
Do you get access denied error only in UI tests that verify focus I would not expect regular user process to get access to Desktop when running in scheduled task. I wonder if non-ui test would cause the same access denied error.

Thank you,
Michael
namso
The deployment conflict is just a warning and should not cause the the run to be aborted, and it should be because you have different file (different time stamp) in MyProjectTests\bin\MyProject.dll and MyProject\bin\MyProject.dll.

Aborting the run should be caused by some other issue. Could you check if the user the scheduled task is run from the user with enough permissions ro read C:\MyProject dir and write to its current directory I would recommend to log in as that user, or lauch cmd.exe from scheduled task, and run mstest.exe in the same environment as when it is run from the task. Also I would recommend to create a file from the task, in the same dir as where mstest would create deployment files. Please let me know if this succeeds or not.

Thanks,
Michael
davidvl
Making the user an administrator of the machine made it so that we did not get the Access Denied error when the scheduled task is run with the user account logged off.

However, any test that is testing focus in any way will then fail. (Is this inherent in the desktop context that is created for a scheduled task when the user account is not already logged on Or are we doing something wrong )

Our solution for now is to leave the user as a Power User and keep him logged on via Remote Desktop.

We're running our automated build/tests on a Windows Server 2003 machine, which I don't think I've mentioned before. We're also using AutomatedQA Automated Build Studio. If either of those two points help.
Challe
Please try running tests on WinXp or try temporarily disable enhanced security on 2003 Server. I can run tests that do not interact with UI/desktop from scheduled task as non-admin user without any problem. For UI tests another option is using remote test run with Agent Process started started in advance from desktop session. We will consider improvement experience of running tests from a scheduled task for v.next.

Thanks,
Michael
OrionsToy
We get Access Denied for every test in the whole solution being executed.
Bordak
When logged in as the user I can:
1. Run all my tests for this solution from within the VS IDE and they run.
2. Run the tests from the command line and they all run.
If I schedule the tests to run using a scheduled task (with the user account logged OFF) then I get the Access Denied error.

I was just making the assumption this file conflict warning was the cause of the Access Denied error. I don't know for sure if it is. I have no idea what else it would be if it wasn't, however, as there are no other warnings or evidence of problems that I can investigate.

The user account in question is a Power User of the machine, and has full access rights to the solution folder and everything under it. Making this user account an administrator of the machine is not an option at this point.
Problems with MSTest.exe

Answer this question