Remote Run from dev machine does not include latest tests


I am new to Team City. I am evaluating it to see if it fits the needs of a new software development department.

I have downloaded the latest version and installed it on a VMware image with 2008 server. It works pretty good - building, reporting, etc. together with VS2008.

The C# source I evaluate with is very simple. 1 solution with 3 projects, 1 windows forms, 1 class library and one test project. I have branched it to a patch branch, created configuration with Team City. Everything works out just fine in regards to building and testing different branches, etc (different build configuration created btw).

But: I have added some new lines of code today. I have also added additional tests. Since my main goal was to test Remote Run with the "commit only if succeed" I created some failing ones to see that everything worked out just fine.

I cannot really say that it worked out at all. I had 4 new tests, it committed my checked out files after running a test containing only 8. I think this was related to the Visual Studio test files that was under source control. At least it seemed to funciton when I checked those out.

But then... I fixed the failing tests and tried Remote run again. It failed and told me that "this and this" line is incorrect. That is weird, since the "local" VS test run reports 12 successfull tests. E.g. ready to submit.

I have tried several times without luck. Btw - it also fails when a run is executed from the central TeamCity installation, but I expected that (the code is after all not committed ).

For the fun of it I committed the files to central repository and started a build in central Team City. And it still fails!!! Well - this indicates that there is actually something wrong with my code (opening the last checkin verifies that the last changes have been included in the build). So I force a get latest on the dev machine and try again. Tests are OK, I then try a new remote run again - still fails.

Checking the build logs I noticed this:

[11:05:47]: Failed to delete file: C:\Program Files\TeamCity\buildAgent\temp\buildTmp\tmp7D21.tmp.teamcity.trx
[11:05:47]: Failed to delete file: C:\Program Files\TeamCity\buildAgent\temp\buildTmp\tmpB614.tmp.teamcity.trx
[11:05:47]: Failed to delete file: C:\Program Files\TeamCity\buildAgent\temp\buildTmp\tmpF1C6.tmp.teamcity.trx

Is it related? Is the information here some sort of cache that unables Team City to understand that the last test is actually correct again? I assume it used the VS test result files in some way. Can it be related to this? Logged in user on build machine is local admin and should have access to everything. E.g. this should not be an issue about rights...

Comment actions Permalink

Update: I updated Team City to start own builds after check in. I added a new test (testproject now has 13) and submitted.
After 15 seconds or so Team City started a new build. It failed - information:

11 tests succeeded, 1 failed.

But I now have 13? Even with the "clean" flag on, Team City is unable to identify my last changes...

To do a test I logged on to my build machine, opened VS2008, forced a get latest, shut down VS2008 and executed a new Team City build from my dev machine.

Result: Build failed.

Comment actions Permalink


It's hard to tell what is wrong so far.
Can you please try to isolate the problem by investigating whether TeamCity correctly passes your changes from IDE to the build agent?

e.g. you can try to compare the state of your local project directory with the build checkout directory on the build agent during the build in quesiton.

You can also refer to the web UI to see what changes were included into your personal build - down to files and lines changed.

The issue with .trx files should not affect correct changes passing to the agent and it will be fixed in the next TeamCity minor update.

BTW, what version control do you use?

Best regards,

Yegor Yarko
Project Manager (TeamCity)
JetBrains, Inc
"Develop with pleasure!"

Comment actions Permalink


Thank you for the reply. During my investigation I hoped I was on to something - build configuration was set to Release while the referred test assemblies was debug. But it did not do me any good.
I have checked out what is actually transferred to the system. Added a new test on the build machine and executed a new build. The system tells me that there is 1 new change, and when I navigate down to it the webinterface shows me that the new test is there.
Test passed are 14, instead of 17 that is the current number.
I do believe that there is an issue related to how the system is set up in regards to url's. I'll look into it and get back to you.
BTW - we use TFS. I think the server is 2005 while the client is 2008.

Comment actions Permalink

I think I am on to something - I believe that the reference to the test assembly in the configuration of the runner is wrong. I earlier specified a the "normal" VS2008 directory for the test file instead of a relative one (e.g. one where the TeamCity agent places the file prior to teststart). So it will always test my old file that is not updated, instead of the one it just build. If this is correct I would like to see some kind of text on this telling the user to "use relative path to the build library, not to a static one that holds a fail you built on this machine 100 years ago", like there are on some of the other settings.

But I haven't yet tested this. Reason? I am unable to find a code (relative path) to the default agent's working directory.
Can you guide me to it? E.g. so I can configure the system to test with the testassembly \%relativepath"\testsupercalculator.dll that was actually just compiled.

Comment actions Permalink

I have added the latest build log file.
I have tried to specify other folders, etc., without any luck.
Any ideas?

Comment actions Permalink

Alright - I finally found the issue...
In my project settings I did not specify the relative path to the agents workdirectory. Instead I used the path directly to the solution file "under" source control. So instad of using something like this:\SuperCalculator\SuperCalculator.sln, I used c:\source\...

Once this was fixed, and the relative path also indicated where the testdll was, everything went OK. Build succeeded both on build server and on local dev machine (e.g. remote run).


Please sign in to leave a comment.