La migliore metodologia per lo sviluppo di app per processori di lunga durata c #

Question

Ho diverse applicazioni di lavoro c # che eseguono varie attività continue: invio di e-mail dalla coda, importazione di nuovi ordini dal database del sito Web al database degli ordini, esecuzione di backup e ripristini del database, esecuzione dell'elaborazione dei dati per OLTP - > OLAP e altre attività correlate. In precedenza, li avevo rilasciati come servizi Windows, ma attualmente li rilasciavo come normali applicazioni console. Sono tutti basati su un framework di task runner comune che ho creato e ne sono soddisfatto, tuttavia non sono sicuro di quale sia il modo migliore per distribuire questi tipi di applicazioni. Mi piace la versione per console perché è semplice e veloce ed è possibile vedere rapidamente l'attività e l'output del programma. L'aspetto negativo è che il computer di lavoro ha diverse schermate della console in esecuzione e diventa disordinato. D'altra parte, il metodo di servizio sembra impiegare molto tempo per essere distribuito e devo vedere i registri degli eventi per vedere i messaggi. Quali sono alcune esperienze / commenti al riguardo?

Answer 1

Mi piace l'approccio alla console. In genere ho impostato le cose in modo da poter passare un interruttore come -unattended che sopprime lo schermo della console.

Answer 2

Il servizio Windows sarebbe una buona scelta, viene eseguito in background, indipendentemente dalla chiusura della sessione corrente, inoltre è possibile configurarlo per l'avvio automatico dopo il riavvio di Windows durante l'esecuzione di un aggiornamento delle patch sul server. Puoi registrare messaggi importanti nel Visualizzatore eventi o nella tabella del database.

Answer 3

Per una cosa del genere, il modo standard di farlo è con i servizi di Windows. Desideri che il servizio venga eseguito sull'account di rete in modo da non richiedere un utente connesso.

Answer 4

Ho lavorato su qualcosa qualche anno fa che aveva problemi simili. Logicamente avevo bisogno di un servizio, ma a volte avevo bisogno di vedere cosa stava succedendo e in generale volevo una storia. Quindi ho sviluppato un servizio che faceva il lavoro, ogni volta che voleva accedere, chiamava i suoi abbonati (implementato come modello di osservatore).

Il servizio ha registrato il proprio data logger (scrivendo su un database) e in fase di esecuzione, l'utente può eseguire una GUI che si è connessa al servizio usando il telecomando per diventare un ascoltatore live!

Answer 5

Voterò per i servizi di Windows. Sarà una vera seccatura gestire quelle applicazioni console.

La distribuzione del servizio Windows è semplice: dopo l'installazione iniziale, è sufficiente disattivarli ed eseguire un XCOPY. Non è necessario eseguire programmi di installazione complicati. È solo semi-complicato la prima volta, e anche allora è solo

installutil MyApp.exe

Configre i servizi da eseguire con un account di dominio per la massima sicurezza e l'interoperabilità più semplice con altre macchine.

Utilizza una combinazione di registri eventi (con errore, avviso e informazioni) per le notifiche importanti e scarica la registrazione dettagliata in un file di testo.

Answer 6

Perché non ottenere il meglio da tutti i mondi e usare qualcosa come:
http://topshelf-project.com/

Ti consentirà di eseguire il tuo programma come riga di comando o servizio Windows.

Answer 7

Non sono sicuro che questo si applichi o meno alle tue applicazioni, ma quando ho alcune applicazioni per console che non dipendono dall'input dell'utente o sono il tipo di applicazioni che fanno semplicemente il loro lavoro ed escono, eseguo tali programmi su un server virtuale, in questo modo non vedo apparire una schermata mentre lavoro e i server virtuali sono facili da creare e riavviare.

Answer 8

Usiamo regolarmente i servizi di Windows come processi in background. Non mi piacciono le app da riga di comando in quanto è necessario accedere al server per poterle eseguire. I servizi vengono eseguiti sempre in background (presupponendo che si avviino automaticamente). Sono anche banali da installare con lo strumento da riga di comando sc.exe presente in Windows. Mi piace meglio del bloat-ware che è installutil.exe. Ovviamente installutil fa di più, ma non ho bisogno di quello che fa. Voglio solo registrare il mio servizio.

Abbiamo anche creato un'infrastruttura in cui disponiamo di un servizio generico .exe che carica .DLL in base alla definizione di un'interfaccia, quindi aggiungendo un nuovo "servizio" è semplice come inserire una nuova DLL e riavviare l'host del servizio.

Tuttavia, abbiamo iniziato ad abbandonare i servizi. Il problema che abbiamo con loro è che bloccano le DLL (per ovvi motivi), quindi è un problema aggiornarle. Dobbiamo interrompere, aggiornare e quindi riavviare. Non difficile, ma passaggi aggiuntivi. Invece ci stiamo spostando in speciali "pagine". nelle nostre app asp.net che eseguono gli attuali lavori in background che dobbiamo fare. C'è ancora un servizio, ma tutto ciò che fa invoca le pagine asp.net in modo da non bloccare nessuna delle nostre DLL. Quindi possiamo sostituire le DLL nella directory bin di asp.net e avviare le normali regole asp.net per il riavvio del dominio di app.