While writing code against the System.Diagnostics.Process tools in C#, I was catching only StandardOutput and parsing it. However, a unit test around this failed on the build server. After a colleague tried on his machine, it failed as well.

Then I found Jon Skeet's answer to a question about why StandardOutput was empty, and he mentioned capturing both StandardOutput and StandardError from System.Diagnostics.Process. Sure enough, we tried that on my colleague's machine and it worked.

My question is, why is something being written to the StandardOutput (stdout) on my machine that's being written to StandardError (sterr) on my colleague's machine and our build server? Is there an environment setting that forces this behavior?

有帮助吗?

解决方案

It turns out that the command I was calling, sqlcmd.exe, was using the SQL Server 2008 (c:\Program Files\Microsoft SQL Server\100\Tools\Binn) version on my colleague's machine and build machine, but the SQL Server 2012 (c:\Program Files\Microsoft SQL Server\110\Tools\Binn) version on my machine. Changing the path variable to point to the SQL Server 2008 version on my machine worked.

Maybe it will be of interest that the "Timeout expired" message is written to stdout instead of stderr in SQL Server 2012's sqlcmd.exe when the .sql script your running takes longer than the sqlcmd.exe -t, query timeout, parameter is set to.

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top