TeamCity Command Line build does not actually start the .cmd file

0
votes

I want to configure my Build configuration so that after my project is built successfully in Build step 1, TeamCity will run a .cmd file. To do that,I've added a second Build step into my build configuration which the Runner type is Command Line, and Command Executable is pointing to my .cmd file. For testing purpose, I just have the .cmd open the Windows Notepad application by a simple script "START C:\Windows\NOTEPAD.EXE". The .cmd file works when I double-click on it (Notepad is opened immediately). The problem is the Build configuration is running successfully through the two steps, but it seems the .cmd is never started. I've checked the build log and it said that the TeamCity has successfully started the .cmd file.

I've tried to update the two TeamCity windows services (TeamCity server and TeamCity Build Agent) to use Local System account, and then stop and restart both of them but it still doesn't work, the .cmd file is never actually started.

2
windowsbatch-filecommand-linecmdteamcity
I don't anything about TeamCity, but, system services running under system accounts are not allowed to interact with the desktop. They run in a separate session. Check with task manager if notepad.exe is running under local system account. If it is not, try to change CommandExecutable to cmd.exe /c "c:\whereyour\batchfileis\do.cmd" – MC ND
But when I updated to Local Service account I've ticked the checkbox to allow the account interact with desktop. – Hung Nguyen
Unless your system is Windows XP, services run in their own session, with their own desktop that is NOT the console desktop. Please see this for detailed info. – MC ND
Thanks for help MC ND, but it does not work even though I've tried to change to local user / domain user. So I think user permission does not the matter – Hung Nguyen
No, it's not a permissions problem. Please see the added answer. – MC ND

2 Answers

1
votes

Answer added to explain concepts exposed in comments

Extracted from Microsoft documentation

  • Windows accommodates multiple logged-on users by putting each user in a separate session. Session 0 is created during startup, with additional sessions added as required. Services have always run in Session 0.

  • Session 0 is reserved exclusively for services and other applications that are not associated with an interactive user session. User applications must run in Session 1 or higher.

  • Session 0 does not support user interfaces. In particular, processes that are running in Session 0 do not have access to the graphics hardware and cannot directly display any UI on the monitor.

0
votes

Thanks for your reply MC. By your suggestion, I've found another way to get my job done, basically it's a solution by mixing a few different tools work together like spexec, .NET Windows Form application.