2009-07-13 19 views
5

Per motivi di apprendimento sto sviluppando un'applicazione di generazione di classi in C# e winforms. Penso che potrebbe andare bene includere una modalità da riga di comando che consente di utilizzare l'applicazione negli script.Devo includere una modalità della riga di comando nelle mie applicazioni?

È buona norma includere una modalità della riga di comando nelle mie applicazioni? Sarebbe meglio avere due programmi diversi, uno con interfaccia grafica in uno per la riga di comando?

risposta

9

In realtà avere un'applicazione C# sia la console sia la GUI sono problematiche. Le applicazioni della console (/t:exe) vengono avviate e quindi il prompt dei comandi attende che finiscano. Applicazioni GUI (/t:winexe) la shell dei comandi li avvia e quindi restituisce immediatamente. Mentre è possibile creare ed eseguire moduli da un'applicazione 'console', sarà sempre visualizzata una console in background. D'altra parte l'applicazione 'Forms' non ha lo stdin, stdout e stderr connessi e, mentre possono comportarsi come gli strumenti della riga di comando e gli argomenti dei comandi di processo, hanno problemi quando sono incorporati negli script (perché l'input/output standard non è collegato).

Se si desidera esporre la funzionalità di entrambe le GUI guidata applicazioni e/pipe-in ​​grado di elaborazione script in batch anche il modo migliore è quello di compilare il funzionalità in una libreria di classi, quindi costruito due applicazioni separate (una GUI una console) che sfruttare quella libreria.

+0

È inoltre possibile creare una finestra di output della console in un'applicazione winexe utilizzando alcuni elementi di win32-api (AllocConsole/AttachConsole), tuttavia presenta ancora alcuni problemi poiché non è stato specificato il sottosistema corretto. –

+0

@Jasper: certo, penso che si possa persino andare dietro agli FCB agli indici 0,1 e 2, ma starei davvero lontano da questo, basta seguire il flusso piuttosto che combattere l'attuale corrente;) –

+0

Non ho mai Ho avuto la necessità di scrivere un'app che gestiva entrambe le GUI e aveva una riga di comando, non ho mai realizzato che fosse così problematico da raggiungere. Risposta molto informativa –

2

Sì. Se si pensa che il programma sarà utile in un ambiente scriptato, includere una modalità riga di comando (senza interfaccia utente) in modo che possa essere utilizzata negli script.

Non deve essere un'applicazione separata, ma può essere. Che tu voglia farlo o meno dipende interamente da te. Immagino che se tu avessi due applicazioni condivideranno gli stessi assiemi logici ma l'interfaccia (una una GUI l'altra una riga di comando) sarebbe solo diversa.

1

La creazione di un'applicazione sulla piattaforma Windows che si comporta correttamente come un'applicazione console può essere problematica è un problema con l'architettura del kernel di Windows in quanto vengono considerati due diversi tipi di applicazioni (hanno un sottosistema diverso che in genere si specifica in le opzioni del compilatore o del linker). Puoi comunque reindirizzare manualmente l'IO e aprire una console da un'applicazione win32 tramite la funzione win32 AllocConsole() e gli amici, ma anche questo ha alcuni problemi. Vedere This Old New Thing post per ulteriori informazioni.

+0

dovrei averlo visto che Raymond ha postato su questo già lol –

1

Se si desidera eseguire il programma di utilità/prgram negli script, è possibile esporlo come COM.

Molti linguaggi di script per Windows hanno la capacità di utilizzare direttamente oggetti COM.

5

Io non sono un programmatore C#, ma quando ho programmare in C++, lo trovo più utile:

1.) Creare sia una libreria condivisa con un C e C++ API per l'esecuzione di nucleo app funzionalità.

2.) Creare uno o più file binari della riga di comando accessibili all'interprete di shell.

3.) Creare un'applicazione GUI per utenti finali tipici, implementata con la libreria (non richiamando i file binari).

Questo separa la logica dell'applicazione dall'interfaccia all'applicazione e consente agli sviluppatori di terze parti di creare interfacce alternative per la stessa funzionalità dell'applicazione. Inoltre, semplifica lo script e allo stesso tempo soddisfa i tipici utenti finali che desiderano una GUI piacevole e brillante.

2

Sono d'accordo con michaelsafyan sulla creazione di una libreria con funzionalità di base.

Quello che vorrei aggiungere è che dovresti controllare anche i cmdlet di PowerShell.

Gran parte dell'attività della riga di comando eseguirà la migrazione a PowerShell e porterà molto sulla tabella.

http://en.wikipedia.org/wiki/Windows_PowerShell

2

Molto spesso crea un'utilità come API. Se ho bisogno di usarlo da una semplice utility da riga di comando, è facile - chiama semplicemente l'API. Se la riga di comando diventa troppo complessa, forse è il momento per un'applicazione Winforms - che può anche chiamare l'API. Se volessi usarlo da PowerShell o da un task MSBUILD, questi sono ancora facili: chiamano semplicemente l'API.

0

Sono d'accordo con @Remus Rusanu.

si dovrebbe creare una libreria di classi delle funzionalità di base e quindi creare l'app GUI (wrapper) per quello.

e un altro beneficio di esso è si potrebbe anche non essere necessario creare un'applicazione a riga di comando, come si può accedere alle funzioni dll .net utilizzando PowerShell ..

si può trovare un esempio nel corso here

0

Un'altra grande idea è incorporare un linguaggio di scripting. Quindi il tuo programma può essere controllato da uno script e tu ricevi tutta la logica, la ramificazione, ecc. Dal linguaggio di scripting "gratuitamente".

Ci sono molte scelte di ciò che è possibile incorporare. Lua è una delle più popolari e destinate a questo scopo ed è una scelta eccellente.

Tuttavia, per un'applicazione generica, darei un'occhiata a incorporare Python. Python è così popolare, avresti un gruppo più numeroso di persone disposte a impegnarsi a scrivere uno script per la tua app.

1

È necessario includere un'interfaccia della riga di comando nell'applicazione, se migliora l'usabilità e il comfort. Ad esempio, chiamare un comando CLI potrebbe essere più veloce dell'avvio della GUI, navigando tra diversi livelli di menu per raggiungere la stessa funzionalità. Si potrebbe chiedere agli utenti dell'applicazione, se troverebbero utile avere una modalità CLI.

Alcune parole sulla sposare CLI & GUI su Windows: Un'applicazione Windows è un'applicazione GUI o un'applicazione console, ma non entrambi. Questo è un problema del sistema operativo e probabilmente non c'è nulla che si possa fare al riguardo. Il sottosistema della console in Windows è orribile e PowerShell non lo ha modificato.

Le opzioni di implementazione in Windows sono:

  • l'approccio due file:

Fornire due file: uno .com con la console, un exe con interfaccia grafica. A causa dell'esplorazione eseguibile sulla riga di comando, il file com verrà eseguito prima dell'exe.

  • console approccio tremolante:

compilare l'applicazione GUI con modalità console, poi subito dopo l'inizio della GUI si potrebbe chiamare FreeConsole() per chiuderla. È un po 'fastidioso, ma funziona. Cattivo: ora hai una finestra della console tremolante. Pro: ancora un file.

Problemi correlati