Alternatives to cmd.exe in C# application

[masaniparesh]

Hi,

To run all commands from C# application i creates Process class in which main process i am passing as an arguments to cmd.exe as given below:

ProcessStartInfo psi = new ProcessStartInfo("cmd.exe", @"/c myapp.pl");
psi.RedirectStandardOutput = true;
psi.RedirectStandardInput = true;
psi.UseShellExecute = false;
psi.CreateNoWindow = true;
psi.LoadUserProfile = true;
//provided domain/user name and password also
Process proc = new Process();
proc = Process.Start(psi);

But this will create two processes cmd.exe and myapp.pl. Is there any alternative to cmd such that it will create only myapp.pl. or is there any switch that can be use with cmd such that it will not create cmd.exe window.

Please not that i am providing user/domain and password and thus psi.loadUserProfile is true and because of this it will definately creat new window as process will be run in the new security user context.

Thanks
Paresh

[Plater]

I already told you before:
ProcessStartInfo psi = new ProcessStartInfo("myapp.pl", "");

There is NO reason to invoke cmd.exe to begin with.

And in the example you just provided, a cmd window would no be created as a result of your code, however is the program you invoke ALSO invokes another program, you have no control over whether or not THAT window will be created.

[masaniparesh]

Hey Plater,

There is the obvious reason that i am invoking all the commands through the cmd.exe because like this only i can spawn any types of processes having any extensions like .msc, .cpl, .exe, .pl, .bat which might not be Win32 application which is only supported by C# Process class. and also i have to use Process class as i am creating process in the new context of the user by provising user/domain name and password.

Hopes you could get this now.

Thanks,
Paresh

[masaniparesh]

Morever the new window will definately be created because of LoadUserProfile is being true in Process class and i am giving user credential together to create new process.

Thanks,
Paresh

[Plater]

There is the obvious reason that i am invoking all the commands through the cmd.exe because like this only i can spawn any types of processes having any extensions like .msc, .cpl, .exe, .pl, .bat which might not be Win32 application which is only supported by C# Process class.

And I keep telling you that is not a true statement.
The Process class can run anything that can be put into the Run dialog from the start menu.
Technically perl and php and other scripts get run through an interpreter program and have to be "set up" to use that. But if you didn't have those things setup, you couldn't invoke them as an argument to cmd.exe either.

[masaniparesh]

Please see the error when i run program in following way:

ProcessStartInfo psi = new ProcessStartInfo(@"c:\local\interactive.pl", "");
psi.RedirectStandardOutput = true;
psi.RedirectStandardInput = true;
psi.UseShellExecute = false;
psi.CreateNoWindow = true;
proc = Process.Start(psi);

C:\>c:\local\InteractiveScript\bin\Release\Interac tiveScript.exe
The specified executable is not a valid Win32 application.

Any comments??

Thanks,
Paresh

[Plater]

Well I see:
ProcessStartInfo psi = new ProcessStartInfo(@"c:\local\interactive.pl", "");
and
C:\>c:\local\InteractiveScript\bin\Release\Interac tive Script.exe

Which is it?
And I would probably guess it's because you have useshellexecute turned off (which gets negated when you run through CMD because it uses a shell execute statement to run it)

[masaniparesh]

InteractiveScript.exe is the C# application's executable which runs interactive.pl perl script.

I have to ser UseShellExecute to false as i am redirecting the input/output and also i am using UserLoadProfile = true to give the user credential to run interactive.pl in the context of user.


Thanks,

[Plater]

Setting UseShellExecute to false means that it won't look up file extension associations. Such as mapping .pl to the perl proccessor, BMP to the default handler.
Forcing it to only run valid win32 EXEs.
CMD.EXE is a valid Win32 application.
Giving CMD the argument tells CMD to run the program, but it's allowed to use a SHELLEXECUTE to look up the default handler for the file type.
Which is why in CMD you can type "mybmp.bmp" and the default handler for BMP files will run the file just as if you had double clicked in the window.

ShellExecute has no bearing on redirecting stdio. As to the user profile stuff, I am unsure, but I would doubt it.