none
LLamar a la línea de comandos MS DOS desde un programa en C#

    Pregunta

  • Buenas a todos, he estado buscando información en la red sobre como lanzar la línea de comandos desde un programa hecho en C#. La cuestión es que necesito solamente lanzar este comando:

    telnet 127.0.0.1 5038 y encontré la clase CommandLineProcess para la cual necesito CommandLib.dll que sólo la puedo descargar de páginas con SPyware. Sabeis alguna otra forma de llamar a  la línea de comandos y las DLL que necesito para ejecutar esta acción.

    Es simple desde mi programa quiero ejecutar el siguiente comando:telnet 127.0.0.1 5038

    También leí un post relacionado pero no es exactamente lo que necesito.

    Un saludo y muchas gracias por adelantado
    jueves, 17 de enero de 2008 12:25

Respuestas

  • No necesitas descargarte nada. con el siguiente fragmento de código debería servir:

     

    Bloque de código

    System.Diagnostics.ProcessStartInfo info = new System.Diagnostics.ProcessStartInfo("CMD.EXE", "/C telnet 127.0.0.1 5038");

    info.Verb = "open";

    System.Diagnostics.Process.Start(info);

     

     

     

    Salud y suerte!

    jueves, 17 de enero de 2008 13:08
    Moderador
  •  Toni Recio Escribió:

    Me temo que andaba equivocado...

     

    Con el Telnet estándar no podemos automatizar instrucciones, con lo que deberías valorar la posibilidad de barajar alternativas como SSH o otros telnet's más completos.


    Eso no es del todo exacto Stick out tongue
    Gracias a una característica poco conocida y apenas documentada de la consola de Windows, es posible automatizar la mayoría de tareas en programas de línea de comandos. Si el programa en cuestión recibe la entrada a través del canal predeterminado (que se corresponde al System.Console en .NET, o stdin en C++), podemos redirigir ese canal, de tal modo que lea de un archivo suministrado por nosotros en vez del teclado. Hoy en día esta técnica se encuentra en el olvido, pero aún quedamos algunos que, tras años trasteando con redirecciones y pipes en *nix y DOS puro nos resistimos a abandonar algo tan útil... qué tiempos aquellos en que los .bat eran ASCII-art en estado puro.. mejor no me pongo nostálgico y voy directo al grano:
    El comando
    programa.exe < archivo.in
    ejecutará "programa.exe" pasándole el contenido de "archivo.in" como si fuese la entrada recibida por el teclado. Del mismo modo, podemos usar
    programa.exe > archivo.out
    para que la salida del programa vaya a "archivo.out" en lugar de ir a la pantalla (se creará el archivo, si aún no existe, o se reemplazará si ya existe); o incluso
    programa.exe >> archivo.out
    para añadir (append en inglés) la salida del comando al archivo: si aún no existe el archivo, no hay diferencia respecto al operador >, pero si el archivo ya existe, se añadirá el texto generado al final, en lugar de reemplazarlo (lo cual es útil para crear un bonito y elegante log en tus scripts de consola).
    Otra característica curiosa es que podemos usar > NUL para "suprimir" la salida de un comando (ejecución silenciosa). NUL es un nombre de archivo reservado al que el DOS (y, por compatibilidad, el Windows) le da un significado especial, significaría algo así como "ningún archivo". Otros nombres reservados que de vez en cuando resultan útiles son CON (representa la consola), LPT1, LPT2, etc (representan los puertos paralelos), PRN (impresora predeterminada, solía ser equivalente a LPT1 hasta que empezó el boom del USB), COM1, COM2, etc (los puertos serie), y puede que me deje alguno. Antes de que hubiese decenas de IDEs con resaltado de sintaxis y demás pijadas para escojer (pero mucho antes), la manera más cómoda de escribir el contenido de un archivo era con "COPY CON archivo" (para archivos nuevos) o "TYPE CON >> archivo" (para añadir a un archivo existente).
    Ups, me esta volviendo a entrar la nostalgia. A lo que vamos:
    Cambia tu archivo Comandos.bat por esto:

    Comandos.bat

    telnet 127.0.0.1 5038 < Comandos.in

    PAUSE

    y pon, en el mismo directorio, un archivo llamado Comandos.in como éste:

    Comandos.in

    call 3355 5555


    Al ejecutar el bat, se ejectutará "telnet 127.0.0.1 5038" y el archivo .in le "tecleará" "call 3355 5555", seguido de Enter (por eso el archivo .in termina con una línea en blanco: no te la olvides o no funcionará).

    Por otro lado, quisiera comentar un par de cuestiones:
    1) Ejecutar el cmd pasándole /C y el archivo .bat es complicarse la vida más de la cuenta. Puesto que Windows reconoceme los ficheros .bat como ejecutables, le podemos pasar el bat directamente. En este caso, además, podríamos prescindir del comando PAUSE: al ejecutar un .bat, si se ha producido salida de datos a la consola, Windows no cerrará la consola de golpe (aunque, si alguna vez necesitas que el bat se cierre al terminar, puedes usar CLS para limpiar la salida).
    2) La opción /C del cmd.exe sirve para ejecutar un comando y finalizar. Puede ser interesante usar el comando /K, que ejecuta el comando y deja cmd.exe abierto (en tal caso habría que usar el comando exit para cerrarlo); aunque eso dependerá de las necesidades concretas de tu proyecto.
    3) La clase System.Diagnostics.Process del .NET soporta la redirección de canales igual que el DOS (aunque la sintaxis es un poco más elaborada). Un código como este:
    Code Snippet

    System.Diagnostics.Process proc=new System.Diagnostics.Process();

    proc.StartInfo.FileName="telnet";
    proc.StartInfo.Arguments="127.0.0.1 5038";
    proc.StartInfo.RedirectStandardInput=
        proc.StartInfo.RedirectStandardOutput=
        proc.StartInfo.RedirectStandardError=

        true;
    proc.StartInfo.UseShellExecute=false;
    proc.StandardInput=new System.IO.StringWriter();
    proc.StandardOutput=new System.IO.StringReader();

    proc.StandardError=new System.IO.StringReader();
    proc.Start();
    proc.StandardInput.WriteLine("call 3355 5555");

    debería conseguir el resultado deseado, con la excepción de que en vez de mostrar la salida en la consola, se la pasará a tu programa (puedes eliminar las lineas correspondientes para evitar esto), de manera que puedes leerla a través de los campos StandardOutput y StandardError del objeto proc (estos campos son objetos StreamReader). Fíjate que esta versión no utiliza archivos externos: ni el .bat ni el .in: el comando, los parámetros, y la entrada que recibirá el telnet se genera a través del código. Incluso, sería posible usar la salida producida por el programa para producir distintas entradas (por ejemplo, si la salida denota que un comando a fallado, el programa podría intentar usar algun comando alternativo).

    davidsting, creo que con esto ya deberías tener suficiente para resolver tu problema Wink

    madlink, desearía poder ayudarte, pero no soy capaz de ver qué es lo que falla en tu código. De todos modos, puesto que shutdown es un archivo "{SystemRoot}\system32\shutdown.exe" por sí mismo ({SystemRoot} es la variable de entorno con ese nombre, normalmente "C:\Windows"), tal vez te convendría pasar el shutdown directamente al Process, en vez de complicarte con el uso de cmd (tal vez haya algun problema que no hemos notado en el paso de parámetros de cmd al comando). Para obtener la carpeta correspondiente a {SystemRoot}, lo más saludable es llamar a System.Environment.GetEnvironmentVariable("SystemRoot"). Por otro lado, también es posible que shutdown se quede atascado esperando la finalización de algún proceso; puedes probar la opción -f para forzar la finalización immediata.
    De modo que el código podría quedar algo parecido a esto:
     
    Code Snippet

    p.EnableRaisingEvents=false;
    p.StartInfo.FileName=Environment.GetEnvironmentVariable("SystemRoot")+"\\system32\\shutdown.exe";
    p.StartInfo.Arguments="-f -s -m \\\\192.168.1.100";
    p.StartInfo.CreateNoWindow=true;
    p.Start();

    No te garantizo que funcione, pero poco cuesta probarlo. Suerte! Wink

    viernes, 30 de mayo de 2008 1:31
  • La solución a tus dos nuevas consultas pasa por crearnos un archivo .BAT. POr ejemplo:

     

     

    Comandos.bat

    telnet 127.0.0.1 5038

    call 3355 5555

    PAUSE

     

     

     

    Para posteriormente ejecutarlo tal y como lo havíamos antes:

     

    Bloque de código

    System.Diagnostics.ProcessStartInfo info = new System.Diagnostics.ProcessStartInfo("CMD.EXE", "/C c:\\scripts\\comandos.bat");

    info.Verb = "open";

    System.Diagnostics.Process.Start(info);

     

     

     

    Te sirve esta solución?

     

    Salud y suerte!

    jueves, 17 de enero de 2008 14:07
    Moderador

Todas las respuestas

  • No necesitas descargarte nada. con el siguiente fragmento de código debería servir:

     

    Bloque de código

    System.Diagnostics.ProcessStartInfo info = new System.Diagnostics.ProcessStartInfo("CMD.EXE", "/C telnet 127.0.0.1 5038");

    info.Verb = "open";

    System.Diagnostics.Process.Start(info);

     

     

     

    Salud y suerte!

    jueves, 17 de enero de 2008 13:08
    Moderador
  • Muchas gracias por responder, la respuesta es la que necesitaba, la cosa es que cuando escribo el código que me has escrito arriba la línea de comandos de MS-DOS desaparece entonces no puedo ver bien si ejecuta la acción o no. ¿Es posible que la línea de comandos MS DOS no se cierre cuando ejecuto el programa?

    Voy a investigar un poco que significa cada parámetro en el código que me has pasado  y seguramente me surgirán nuevas preguntas.

    Muchas gracias de nuevo

    Un saludo
    jueves, 17 de enero de 2008 13:20
  • Hola a todos,

    El problema de esto es que yo necesito llamar primero a telnet 127.0.0.1 5038  y que esto sea ejecutado en la consola de comandos yo debería entrar en una aplicación dentro de esa misma consola de comandos para ejecutar el siguiente comando call 3333 5555, de tal modo que si yo hago :

    System.Diagnostics.ProcessStartInfo info1 = new System.Diagnostics.ProcessStartInfo("CMD.EXE", "/C call 3333 5555");

                info1.Verb = "open";

                System.Diagnostics.Process.Start(info1);

    Me abriría otra línea de comandos, y yo lo que quiero sería :

    telnet 127.0.0.1 5038
    call 3333 5555

    en la misma consola de comandos y no en 2, sabe alguien como lo puedo hacer??


    Muchas gracias por adelantado
               
    jueves, 17 de enero de 2008 13:39
  • La solución a tus dos nuevas consultas pasa por crearnos un archivo .BAT. POr ejemplo:

     

     

    Comandos.bat

    telnet 127.0.0.1 5038

    call 3355 5555

    PAUSE

     

     

     

    Para posteriormente ejecutarlo tal y como lo havíamos antes:

     

    Bloque de código

    System.Diagnostics.ProcessStartInfo info = new System.Diagnostics.ProcessStartInfo("CMD.EXE", "/C c:\\scripts\\comandos.bat");

    info.Verb = "open";

    System.Diagnostics.Process.Start(info);

     

     

     

    Te sirve esta solución?

     

    Salud y suerte!

    jueves, 17 de enero de 2008 14:07
    Moderador
  • Muchas gracias de nuevo por responder, ahora he creado el archivo .BAT como me dijiste, ahora consigo ver que la conexión TELNET se realiza de forma adecuada, pero el problema ahora es que la línea de comandos no recoge el comando call 3333 5555, es como si se quedase esperando o si hiciese falta un comando ENTER explícito en el archivo .bat. para que captase una vez que entra en la aplicación Telnet los siguientes comandos.

    Un saludo y muchas gracias
    jueves, 17 de enero de 2008 14:46
  • Me temo que andaba equivocado... Sad

     

    Con el Telnet estándar no podemos automatizar instrucciones, con lo que deberías valorar la posibilidad de barajar alternativas como SSH o otros telnet's más completos.

     

    jueves, 17 de enero de 2008 16:49
    Moderador
  • Muchas gracias de todas formas, he probado SSH y creo que sólo puedo utilizar telnet para llamar a la otra aplicación. Ya que he estado mirando el código fuente de la aplicación destino y sólo tiene cubierto el caso de la llamada mediante telnet. ¿Sabrías si con la clase CommandLineProcess se podría hacer? Es que he estado investigando un poco y he visto que la clase implementa unos métodos que pueden servirme, el problema es que como requerimientos necesito la clase CommandLib.dll y esa sólo la he encontrado para descargarme en una página que pone SpyWare, y no me fío mucho

    Te estoy muy agradecido por las respuestas

    Un saludo
    jueves, 17 de enero de 2008 17:55
  • No me suena nada de la libreria que comentas la verdad... Sad

     

    Yo creo que deberías buscar alguna herramienta cliente de Telnet que permita scripting.

     

    Por ejemplo:

    http://hp.vector.co.jp/authors/VA002416/teraterm.html

     

    jueves, 17 de enero de 2008 20:27
    Moderador
  • Hola, yo ando con un problema parecido, necesito tirar el comando shutdown con parametros pero lo unico que hace es abrir una ventana cmd en negro y no hace mas nada.. alguna idea?
               
               
    Code Snippet

                p.EnableRaisingEvents = false;
                p.StartInfo.FileName = "C:\\WINDOWS\\system32\\cmd.exe";
                p.StartInfo.Arguments = " /c shutdown -s -m \\\\192.168.1.100
                p.StartInfo.CreateNoWindow = true;
                p.start();



    Gracias
    madlink@gmail.com
    martes, 13 de mayo de 2008 1:13
  •  Toni Recio Escribió:

    Me temo que andaba equivocado...

     

    Con el Telnet estándar no podemos automatizar instrucciones, con lo que deberías valorar la posibilidad de barajar alternativas como SSH o otros telnet's más completos.


    Eso no es del todo exacto Stick out tongue
    Gracias a una característica poco conocida y apenas documentada de la consola de Windows, es posible automatizar la mayoría de tareas en programas de línea de comandos. Si el programa en cuestión recibe la entrada a través del canal predeterminado (que se corresponde al System.Console en .NET, o stdin en C++), podemos redirigir ese canal, de tal modo que lea de un archivo suministrado por nosotros en vez del teclado. Hoy en día esta técnica se encuentra en el olvido, pero aún quedamos algunos que, tras años trasteando con redirecciones y pipes en *nix y DOS puro nos resistimos a abandonar algo tan útil... qué tiempos aquellos en que los .bat eran ASCII-art en estado puro.. mejor no me pongo nostálgico y voy directo al grano:
    El comando
    programa.exe < archivo.in
    ejecutará "programa.exe" pasándole el contenido de "archivo.in" como si fuese la entrada recibida por el teclado. Del mismo modo, podemos usar
    programa.exe > archivo.out
    para que la salida del programa vaya a "archivo.out" en lugar de ir a la pantalla (se creará el archivo, si aún no existe, o se reemplazará si ya existe); o incluso
    programa.exe >> archivo.out
    para añadir (append en inglés) la salida del comando al archivo: si aún no existe el archivo, no hay diferencia respecto al operador >, pero si el archivo ya existe, se añadirá el texto generado al final, en lugar de reemplazarlo (lo cual es útil para crear un bonito y elegante log en tus scripts de consola).
    Otra característica curiosa es que podemos usar > NUL para "suprimir" la salida de un comando (ejecución silenciosa). NUL es un nombre de archivo reservado al que el DOS (y, por compatibilidad, el Windows) le da un significado especial, significaría algo así como "ningún archivo". Otros nombres reservados que de vez en cuando resultan útiles son CON (representa la consola), LPT1, LPT2, etc (representan los puertos paralelos), PRN (impresora predeterminada, solía ser equivalente a LPT1 hasta que empezó el boom del USB), COM1, COM2, etc (los puertos serie), y puede que me deje alguno. Antes de que hubiese decenas de IDEs con resaltado de sintaxis y demás pijadas para escojer (pero mucho antes), la manera más cómoda de escribir el contenido de un archivo era con "COPY CON archivo" (para archivos nuevos) o "TYPE CON >> archivo" (para añadir a un archivo existente).
    Ups, me esta volviendo a entrar la nostalgia. A lo que vamos:
    Cambia tu archivo Comandos.bat por esto:

    Comandos.bat

    telnet 127.0.0.1 5038 < Comandos.in

    PAUSE

    y pon, en el mismo directorio, un archivo llamado Comandos.in como éste:

    Comandos.in

    call 3355 5555


    Al ejecutar el bat, se ejectutará "telnet 127.0.0.1 5038" y el archivo .in le "tecleará" "call 3355 5555", seguido de Enter (por eso el archivo .in termina con una línea en blanco: no te la olvides o no funcionará).

    Por otro lado, quisiera comentar un par de cuestiones:
    1) Ejecutar el cmd pasándole /C y el archivo .bat es complicarse la vida más de la cuenta. Puesto que Windows reconoceme los ficheros .bat como ejecutables, le podemos pasar el bat directamente. En este caso, además, podríamos prescindir del comando PAUSE: al ejecutar un .bat, si se ha producido salida de datos a la consola, Windows no cerrará la consola de golpe (aunque, si alguna vez necesitas que el bat se cierre al terminar, puedes usar CLS para limpiar la salida).
    2) La opción /C del cmd.exe sirve para ejecutar un comando y finalizar. Puede ser interesante usar el comando /K, que ejecuta el comando y deja cmd.exe abierto (en tal caso habría que usar el comando exit para cerrarlo); aunque eso dependerá de las necesidades concretas de tu proyecto.
    3) La clase System.Diagnostics.Process del .NET soporta la redirección de canales igual que el DOS (aunque la sintaxis es un poco más elaborada). Un código como este:
    Code Snippet

    System.Diagnostics.Process proc=new System.Diagnostics.Process();

    proc.StartInfo.FileName="telnet";
    proc.StartInfo.Arguments="127.0.0.1 5038";
    proc.StartInfo.RedirectStandardInput=
        proc.StartInfo.RedirectStandardOutput=
        proc.StartInfo.RedirectStandardError=

        true;
    proc.StartInfo.UseShellExecute=false;
    proc.StandardInput=new System.IO.StringWriter();
    proc.StandardOutput=new System.IO.StringReader();

    proc.StandardError=new System.IO.StringReader();
    proc.Start();
    proc.StandardInput.WriteLine("call 3355 5555");

    debería conseguir el resultado deseado, con la excepción de que en vez de mostrar la salida en la consola, se la pasará a tu programa (puedes eliminar las lineas correspondientes para evitar esto), de manera que puedes leerla a través de los campos StandardOutput y StandardError del objeto proc (estos campos son objetos StreamReader). Fíjate que esta versión no utiliza archivos externos: ni el .bat ni el .in: el comando, los parámetros, y la entrada que recibirá el telnet se genera a través del código. Incluso, sería posible usar la salida producida por el programa para producir distintas entradas (por ejemplo, si la salida denota que un comando a fallado, el programa podría intentar usar algun comando alternativo).

    davidsting, creo que con esto ya deberías tener suficiente para resolver tu problema Wink

    madlink, desearía poder ayudarte, pero no soy capaz de ver qué es lo que falla en tu código. De todos modos, puesto que shutdown es un archivo "{SystemRoot}\system32\shutdown.exe" por sí mismo ({SystemRoot} es la variable de entorno con ese nombre, normalmente "C:\Windows"), tal vez te convendría pasar el shutdown directamente al Process, en vez de complicarte con el uso de cmd (tal vez haya algun problema que no hemos notado en el paso de parámetros de cmd al comando). Para obtener la carpeta correspondiente a {SystemRoot}, lo más saludable es llamar a System.Environment.GetEnvironmentVariable("SystemRoot"). Por otro lado, también es posible que shutdown se quede atascado esperando la finalización de algún proceso; puedes probar la opción -f para forzar la finalización immediata.
    De modo que el código podría quedar algo parecido a esto:
     
    Code Snippet

    p.EnableRaisingEvents=false;
    p.StartInfo.FileName=Environment.GetEnvironmentVariable("SystemRoot")+"\\system32\\shutdown.exe";
    p.StartInfo.Arguments="-f -s -m \\\\192.168.1.100";
    p.StartInfo.CreateNoWindow=true;
    p.Start();

    No te garantizo que funcione, pero poco cuesta probarlo. Suerte! Wink

    viernes, 30 de mayo de 2008 1:31
  • Bueno les tengo una pregunta por que se me ha heco muy dificil.

    por ejemplo tengo un archibo ejecutable

    X.exe dentro de este puedo correr lineas de comando OK.

    entonces estoy tratando de realizar lo siguiente.

     

    If TextBox1.Text = "" Then

    MsgBox(

    "cargar el archivo X")

     

    Else

    FileOpen(1,

    "c:\cortar.bat", OpenMode.Output) ' Open file for output.

    Print(1,

    "@hecho") ' Print text to file.

    PrintLine(1)

    ' Print blank line to file.

    PrintLine(1,

    "cd C:\Archivos de programa\Ruta de X") ' Print in two print zones.

    PrintLine(1,

    "X.exe " & Chr(34) & CStr(TextBox1.Text) & Chr(34) & " " & Chr(34) & "comando de X.regla" & Chr(34) & "") ' Separate strings with a tab.

    PrintLine(1,

    "pause")

    FileClose(1)

    ' Close file.

    hasta aca todo OK me genera el BAT perfecto lo ejecuto y me realiza la accion pero cuando quiero ejecutar el bat desde VB

    Shell(

    "c:\cortar.bat")

    End If

     

    End Sub

     

     

    me da error me dice X.exe no es una aplicacion Win32 valida.

    Para ver quien me podria ayudar a terminar este problema ya busque mucha info pero todo al desvio

    gracias


    conocuica
    martes, 23 de junio de 2009 20:47
  • no se si este sea tu caso. estoy haciendo una bliblioteca de juegos. y necesito ejecutarlos desde mi software. con los .exe no hay problemas. pero tengos juegos que los ejecutables son .bat ahi empezo el lio. cuando los ejecuto desde el formulario el sistema no ubica la direccion que le asignte al .bat y abre el cmd un pantallaso negro y se cerraba. hice de todo. no habia respuesta en la red. pero se me ocurrio crear un acceso directo del .bat y luego ejecutarlo desde mi software con el process.start(Direccion del acceso directo). y listo me funciono y esta andando bien mi aplicacion 
    viernes, 10 de febrero de 2012 15:20
  • no se si este sea tu caso. estoy haciendo una bliblioteca de juegos. y necesito ejecutarlos desde mi software. con los .exe no hay problemas. pero tengos juegos que los ejecutables son .bat ahi empezo el lio. cuando los ejecuto desde el formulario el sistema no ubica la direccion que le asignte al .bat y abre el cmd un pantallaso negro y se cerraba. hice de todo. no habia respuesta en la red. pero se me ocurrio crear un acceso directo del .bat y luego ejecutarlo desde mi software con el process.start(Direccion del acceso directo). y listo me funciono y esta andando bien mi aplicacion 

    En general, cuando te encuentres creando archivos secundarios (como en este caso un acceso directo) para ejecutar procesos con System.Diagnostics.Process, suele ser síntoma de que estás pasando algo por alto.

    En este caso, todo apunta a que el .bat trabaja con rutas relativas, y por lo tanto necesita ejecutarse desde el directorio donde se encuentra.

    Para ser más específicos: todo proceso en ejecución tiene un directorio de trabajo o directorio activo. El ejemplo más obvio es cuando tienes abierta una terminal de consola (como el cmd.exe de Windows) y usas el comando "CD": lo único que hace este comando es cambiar el directorio de trabajo de la terminal al que le especificas.

    Del mismo modo, el proceso que esté llamando a tu biblioteca tendrá su propio directorio de trabajo, y es muy poco probable que sea el mismo que el directorio desde el que el .bat necesita ejecutarse. Aquí tenemos dos o tres opciones:

    La primera opción, que viene a ser la chapuza mayúscula, seria cambiar el directorio de trabajo desde la librería. Para ello bastaría con asignar el directorio deseado a la propiedad System.Environment.CurrentDirectory. Esto sería razonable desde un programa independiente, pero como he dicho resulta una chapuza peligrosa cuando lo haces desde una librería: la finalidad de cualquier librería es ser en cierto modo independiente de los programas que enlacen con ella. Usando esta técnica, estás "prohibiendo" a esos programas usar el directorio de trabajo para sus propios fines (ya que se lo estás cambiando sin avisar). Desde un punto de vista más filosófico, vendría a ser una cuestión de respeto: el directorio de trabajo pertenece al proceso; y el proceso pertenece al programa, no a la librería, de modo que la librería no debería cambiar el directorio.

    Las otras dos opciones son en realidad dos variaciones de la misma idea: hacer que el .bat se ejecute con su propio directorio de trabajo sin cambiar el directorio del ejecutable principal. Un modo de hacer esto es configurarlo a través de un acceso directo, como has hecho tú. Pero esto resulta engorroso (el acceso directo necesita un directorio de trabajo desde el que buscar el bat, por lo que a la que muevas las cosas recreas el problema), y poco fiable: los accesos directos suelen guardar tanto la referencia al destino como el directorio de trabajo a asignarle como rutas absolutas; no puedes contar con que el usuario final de tu proyecto tenga la misma estructura de disco que tu sistema. Para rematar, el acceso directo es un archivo más con el que tendremos que lidiar; no es que sea el fin del mundo, pero es un tedio, y nos lo podemos ahorrar.

    Así que nos vamos a la última opción. Dicen que a la tercera va la vencida ;-)

    La clase System.Diagnostics.ProcessStartInfo tiene una propiedad muy conveniente llamada WorkingDirectory. Ésta nos permite definir el directorio de trabajo para el proceso que estamos creando, sin depender de ficheros de acceso directo con rutas absolutas y sin liársela parda al programa que usa la librería si necesita resolver rutas relativas al directorio de trabajo.

    Si tu código es capaz de encontrar la ruta al .bat para pasársela al Process.Start, encontrar la ruta a usar como directorio de trabajo no es más que una mera manipulación de strings.

    miércoles, 29 de febrero de 2012 0:24
  • Hola, tengo este ejemplo.

    Mi aplicacion en c# hace que a la pulsacion de un boton en el WinForm llama al cmd y un comando especifico que me reproduce un video en consola.. por otra parte desde un raspberry(linux) habro el putty que es como la consola de este raspberry y ejecuto un comando que pone al raspberry en escucha de algun streaming el cual es enviado desde el boton de mi WinForm(cmd, /k comando) que sera reproducido en un televisor gracias al raspberry (este hace la funcion de puente por decirlo asi entre el video que se ejecuta en consola mediante la pulsacion del boton del WinForm y el raspberry lo escucha como streaming y lo reproduce en el televisor.. En conclusion a la hora que yo pulso el boton ejecuto un comando que reproduce un video con su ruta, pero como haria para elegir otro video es decir al pulsar el boton el comando tiene una ruta de video establecido.. quisiera poder llamar a la ruta del video y pasarlo como parametro para poder reproducir cualquier video. Ojala puedan ayudarme y entendido gracias :D

    jueves, 22 de mayo de 2014 15:38