C# Console Command wird nicht ausgeführt

[Tician]

Moin!

Da mir bisher immer super geholfen wurde wende ich mich mal wieder an euch

Ich möchte über mein C# Programm (Console Application) auch einen Windows-Kommandozeilen-Befehl absetzen und mein Code dazu sieht so aus:

string cmdText = "\"C:\\Program Files (x86)\\Adobe\\Reader 11.0\\Reader\\AcroRd32.exe\" /t \"C:\\Temp\\abcde.pdf\"";
System.Diagnostics.Process.Start("cmd.exe", cmdText);

(soll eigentlich eine pdf-Datei drucken)

bzw habe ich auch das hier probiert:

System.Diagnostics.Process command = new System.Diagnostics.Process();
System.Diagnostics.ProcessStartInfo info = new System.Diagnostics.ProcessStartInfo();
info.WindowStyle = System.Diagnostics.ProcessWindowStyle.Normal;
info.FileName = "cmd.exe";
info.Arguments = "\"C:\\Program Files (x86)\\Adobe\\Reader 11.0\\Reader\\AcroRd32.exe\" /t \"C:\\Temp\\abcde.pdf\"";                command.StartInfo = info;
command.Start();

Es wird mir leider kein Befehl ausgegeben, das einzige was passiert ist das ich ein offenes command-Fenster habe, also der Prozess an sich wird ausgeführt aber aus irgendeinem Grund wird das Kommando nicht übernommen/übergeben/ausgeführt.

Öffne ich manuell die Konsole und tippe den Befehl ein funktioniert es wunderbar, der einzige Unterschied sind die escape-Zeichen für die Anführungsstriche und Backslashes - kann das zu einem Fehler führen? Ich bekomme keinen Error, gibt es etwas das ich tun kann um zu sehen warum es nicht funktioniert?

Das Projekt liegt auf einem Netzlaufwerk (Y:), dementsprechend steht in den geöffneten Konsolenfenstern auch

Y:\Pfad zu meinem Projekt Ordner\Debug>

aber laut meinem Ausbilder sollte es trotzdem funktionieren den Adobe Acrobat Reader von C: aufzurufen. Sieht jemand einen Fehler, fehlt mir vielleicht etwas oder habe ich die Escape-Zeichen falsch gesetzt?

 

Grüße

Tician

[JustAnotherName]

Huhu,

versuch das mal:

String acrobatPath = "C:\\Program Files (x86)\\Adobe\\Reader 11.0\\Reader\\AcroRd32.exe";
String pdfPath = "C:\\Temp\\abcde.pdf";

Process cmdProcess = new Process();
cmdProcess.StartInfo.FileName = "cmd.exe";
cmdProcess.StartInfo.RedirectStandardInput = true; 
cmdProcess.StartInfo.UseShellExecute = false;
cmdProcess.Start();

cmdProcess.StandardInput.WriteLine("\""+acrobatPath+"\" \""+pdfPath+"\"");
cmdProcess.StandardInput.Flush();
cmdProcess.StandardInput.Close();
cmdProcess.WaitForExit(); 

 

[JustAnotherName]

//Edit: Bin beim bearbeiten wohl ins falsche Textfeld gekommen 

Zitat

Öffne ich manuell die Konsole und tippe den Befehl ein funktioniert es wunderbar

Mit dem Schnipsel ist es so, als würdest Du in die Konsole schreiben und Enter drücken.

Mit "RedirectStandardOutput = true;" und "cmdProcess.StandardOutput" kannst du auch die Ausgabe der Konsole bekommen.

Bearbeitet 23. September 2016 von Anluin

[Tician]

@Anluin
Vielen Dank, ich habe aber eine Lösung gefunden die perfekt gepasst hat:

                ProcessStartInfo info = new ProcessStartInfo();
                info.Verb = "print";
                info.FileName = "C:\\Temp\\abcde.pdf";
                info.CreateNoWindow = true;
                info.WindowStyle = ProcessWindowStyle.Hidden;

                Process p = new Process();
                p.StartInfo = info;
                p.Start();

                p.WaitForInputIdle();
                System.Threading.Thread.Sleep(3000);
                if (false == p.CloseMainWindow())
                    p.Kill();

Für den nächsten der es vielleicht gebrauchen kann Es öffnet zwar den Adobe Reader (wie jede andere Lösung die ich noch gefunden habe), schließt ihn aber auch wieder, es gibt keine Überreste im Taskmanager.

[Whiz-zarD]

if(false == p.CloseMainWindow())
	p.Kill();

Das ist echt gruselig zu lesen.
Erst mal ist es unnötig, da ein 

if(!p.CloseMainWindow())
	p.Kill();

reicht, da die Methode CloseMainWindow() schon ein Boolean zurückgibt und deswegen nicht mehr mit einem Boolean verglichen werden muss. Wenn der Compiler dies nicht wegoptimieren würde, würden wir sogar ein oder mehrere Prozessorinstruktionen zu viel machen.

Und Zweitens stammt diese defensive Schreibweise 

if(Prüfung == Variable)
	...

noch aus den C-Zeiten, da man innerhalb einer If-Anweisung auch Variablendeklarationen vornehmen konnte. Dies geschieht dann durch ein einfaches Gleichheitszeichen. Man konnte also in C folgendes schreiben:

if(Variable = Prüfung)
	...

und es war kompilierfähig. Hatte aber einen unvorhersehbaren Effekt. Daher entschied man sich oft für die obere Variante, denn wenn man dort ein Gleichheitszeichen weglässt gibt es ein Kompilierfehler aber es liest sich schlechter, da wir im Sprachgebrauch von Links nach Rechts lesen. Wir würden also zuerst die Bedingung lesen, die erfüllt sein muss und dann erst, worauf diese Bedingung passen soll. Es fühlt sich also vom Sprachgebrauch besser an, wenn wir erst mal schreiben, was wir überprüfen wollen und dann die Bedingung. Also:

if(Variable == Prüfung)
	...