I have an MSBuild task that executes (among other things) a call to xcopy. What I have found is that this call to xcopy executes correctly when I run my MSBuild task from a batch file, and fails to execute or produce any output that would allow me any idea what is going on when that same batch file is called from another C# application with a System.Diagnostics.Process.
Both processes are launched with more or less the same structure:
waitProc.StartInfo.Arguments = "/C [executable]"; waitProc.StartInfo.FileName = "cmd.exe"; waitProc.StartInfo.UseShellExecute = false;
Furthermore by changing the "UseShellExecute" from false to true on the xcopy command I can make this succeed in both use cases, however the command fails to run in a third use case. The third use case being our automated build system which is a windows service calling msbuild directly. In the case of the failure on our build machine the copy command hangs indefinitely which is, I believe, because the System.Diagnostics.Process tries to display a window, and services do not have a Windows desktop session associated with them, so they cannot display windows.
I have tried using the "CreateNoWindow" property, and I've tried setting the "WindowStyle" to "ProcessWindowStyle.Hidden," but that does not change the behavior on the build machine.
All of this said, what I really want to know is what exactly the UseShellExecute property does, because it seems to do a whole lot more than the MSDN documentation suggests.
Thanks.
Start(ProcessStartInfo) Starts the process resource that is specified by the parameter containing process start information (for example, the file name of the process to start) and associates the resource with a new Process component.
The word "shell" in this context ( UseShellExecute ) refers to a graphical shell (similar to the Windows shell) rather than command shells (for example, bash or sh ) and lets users launch graphical applications or open documents.
Diagnostics provides a set of attributes and classes to interact with the system process, event managers, performance counts, etc. This namespace can help us too in debugging jobs. Let's review the useful actions inside System. Diagnostics namespace.
The Process component is a useful tool for starting, stopping, controlling, and monitoring applications. The System. Diagnostics namespace provides classes that allow you to interact with system processes, event logs, and performance counters. Imports System.Diagnostics.
ProcessStartInfo.UseShellExecute tells the Process to use the Windows Shell to execute the specified application.
Without this set, you can only execute an EXE file directly. By setting this, you allow the Windows Shell to be used, which allows things such as specifying a .doc file and having the associated program open the file.
However, using the Windows Shell requires a valid desktop context, which is why your third use case fails.
In general, using cmd.exe
is problematic unless you're using the Windows Shell. You may want to just write the code to handle your "batch" operation directly - ie: use the methods from types in the System.IO namespace to do your copying. This would avoid this issue entirely.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With