In questa breve serie di Post, utilizzeremo quanto finora sviluppato per iniziare a costruire un’interfaccia avanzata per la console del nostro servizio Windows, in modo da poter costruire i Job che gli faremo eseguire. In Questa prima parte porteremo in libreria il CloseableTabItem che abbiamo costruito nel precedente post e faremo un paio di modifiche interessanti, nel post successivo andremo a creare la User Interface per gestire i Job all’interno della console del servizio.
Comments closedTag: Csharp
Un post che riporta ed estende un tutorial di csharpcorner e dimostra come modificare un controllo standard microsoft (il TabItem del TabControl) in modo da creare un interfaccia simile all’editor di visual studio, da utilizzare come bozza applicativa per le nostre interfacce WPF.
Comments closed
Facciamo il fine tuning dello User Control disegnato nel post precedente a questo e disponibile QUI in questo articolo modificheremo le semplici textbox inserite per il primo test e aggiungeremo un DateTimePicker per la data della prossima esecuzione del Job, un DateTimeUpDown per l’ora della prossima esecuzione del job, in IntegerUpDown per la gestione dell’intervallo di esecuzione ed una combobox per selezionare le connessioni disponibili sul sistema per l’esecuzione dei job. Per fornire la lista alla combobox aggiungiamo ai parametri di configurazione del servizio e della sua console un file che conterrà tutte le stringhe di connessione valide a SQL Server che vogliamo memorizzare.
Comments closed
In questo post, proseguiamo lo sviluppo della console per il servizio MiniSqlAgent che stiamo sviluppando per dimostrare come costruire un servizio windows funzionante e non banale ed una applicazione WPF che ne gestisca l’amministrazione in tutti i suoi aspetti. Nel post precedente abbiamo generato una classe per definire un Job per il nostro servizio che contiene funzionalità minimali, adesso realizziamo uno User Control WPF per poter generare un Job e salvarlo su un file su disco, e testeremo lo User Control nella applicazione della nostra console.
Comments closed
Un post per definire la classe entity che contiene i dati di base per costruire un Job che permetta di eseguire uno statement SQL ad intervalli regolari. Propedeutica allo sviluppo dell’interfaccia di gestione e del servizio Mini SQL Agent.
Comments closed
Introduciamo in questo post quello che vogliamo realizzare con il servizio Windows che abbiamo fino a qui sviluppato per spiegare alcuni concetti fondamentali nella generazione di una applicazione .NET non banale. Il nostro Servizio Windows in questo momento è stato costruito in modo che il suo lavoro è fornire dei messaggi ad intervalli regolari, ora vogliamo trasformarlo in un Agent in grado di eseguire script Transact SQL su uno o più server SQL a cui può collegarsi.
Per costruire un sistema di questo genere, per prima cosa dobbiamo costruire gli oggetti che possono ospitare gli script SQL, una volta costruiti questi oggetti, dobbiamo creare il codice che li eseguirà all’interno del nostro servizio.
Comments closed
In questo post aggiungeremo la funzionalità di invio messaggi tramite HTTP al servizio MiniSqlAgent che abbiamo sviluppato nei post precedenti e la funzionalità di ricezione dei messaggi alla sua console di supporto. Per farlo aggiorneremo l’ HTTP sender, aggiorneremo il sistema di Log del servizio, aggiungeremo alcuni parametri di configurazione al servizio, aggiungeremo inoltre una Window che fornirà un real time monitor del servizio all’amministratore.
Comments closed
Nel post precedente abbiamo creato una libreria generica contenente le classi che implementano un HTTP listener ed un HTTP sender, in questo realizziamo una applicazione di test WPF che ci permette di verificare il corretto funzionamento delle due classi, in seguito proveremo ad inserire questi due oggetti in una applicazione reale, o meglio in due applicazioni, il servizio windows che abbiamo sviluppato e la sua console.
Comments closed
Introduzione
Un servizio windows, per definizione non è dotato di interfaccia utente, è un po’ come una scatola nera con dei plug che riceve input e produce output ma senza alcuna interazione con l’utente.
Un servizio semplice, potrebbe avere bisogno esclusivamente di una console, come quella da noi costruita nei post precedenti, per configurarlo e per verificare che parte e si ferma. Potremmo anche aggiungere alla console creata un sistema veloce per consultare i log del servizio e fermarci qui.
Se il servizio è più complesso di quello che scrive dati su un file di testo che fin qui abbiamo sviluppato, l’amministratore potrebbe aver bisogno anche di valutarne il carico di lavoro, la funzionalità e quindi profilarne il funzionamento per potere ad esempio rispondere alla domanda: “Ma perché è così lento.” facendo un fine tuning della parametrizzazione del servizio.
Per fare questo abbiamo bisogno che il servizio sia in grado di essere monitorato in tempo reale, usando il log verboso che abbiamo introdotto nel primo sviluppo del servizio potremmo usare un file system watcher e monitorare il file di log, ma è un approccio un po’ troglodita, soprattutto se il log è massiccio.
A questo punto entrano in gioco gli oggetti che abbiamo inserito nel titolo di questo post. Un servizio può essere dotato di una interfaccia per comunicare con il mondo (in questo caso con il PC che lo ospita) utilizzando il protocollo HTTP, l’interfaccia può essere bidirezionale, quindi il servizio potrebbe ricevere dei comandi da un programma esterno e potrebbe trasmettere dati e richieste ad un programma esterno.
Ecco perché abbiamo deciso di sviluppare le classi necessarie a creare questo tipo di comunicazione.
Comments closed
In questo post illustriamo come costruire il codice necessario ad avviare e fermare un servizio da una applicazione WPF e nell’effettuare questa dimostrazione spieghiamo come costruire alcuni converter, come modificare lo stile di un controllo in base alla variazione di un dato sul View Model del contesto, e spiega come utilizzare i Command di WPF per pilotare i menu, sia agganciando i Command di sistema forniti dalle librerie, sia creando dei command specifici per le esigenze delle nostre applicazioni.
Comments closed