Sottotitolo: Tutto quello che Vi serve sapere per creare un bel documento Microsoft Word da codice C#.

L'esigenza è semplice: ottenere dai dati gestiti dal nostro fantastico software un documento Microsoft Word che riporti un'analisi degli stessi.

Manco a dirlo il documento deve avere delle tabelle, con i dati presentati in modo sensato e graficamente convincente.

L'attività di per se è abbastanza semplice, ma ritengo non sia altrettanto semplice trovare tutte le informazioni necessarie.

Per esempio come mettere una tabella nell'header del documento in modo tale che lo stesso sia riportato in ogni pagina ?? Come annegare dentro questa un'immagine ?? Come porre dei testi in verticale ? Semplici domande e le cui risposte non sono facilmente rintracciabili.

Ci ho messo un pò a reperire tutte le dritte necessarie, per cui ho pensato di raggrupparle tutte insieme per aiutare altri che possano avere un'esigenza simile.

Per iniziare occorre dire che tutte le funzionalità qui presentate usano esclusivamente le API messe a disposizione da Microsof Office: è banale sottolinearlo, ma occorre che sia sulla macchina di sviluppo su cui andremo a implementare il codice, che sulla macchina destinataria dell'utilizzatore, il pacchetto office deve essere correttamente installato e funzionante.

Con il rischio di offenderVi ulteriormene devo anche dire che occorre anche aggiungere al progetto il riferimento a Microsft Office Object Library. Fatto questo avremo la possibilità di accedere a tutte le funzioni viste nel seguito.

Altrimenti..... No office... No party.....

In questi giorni mi è capitata la necessità di investigare le cause di un comportamento anomalo che occorreva in modo casuale in un software di nostra produzione, e che si appoggia su un'istanza di database di Sql Server.

Il punto incriminato era una stored procedure, che veniva eseguita all'interno di una transazione molto complessa, con diversi punti del codice e diversi alltri oggetti di Sql Server richiamati alla bisogna.

La cosa più ovvia è stata mettere un sistema che permettesse di eseguire il log degli eventuali errori in modo da eseguire in modo efficace l'Handling SQL Server Errors.

Dopo un pò di ricerche ho pensato di porre il codice incriminato un blocco try/catch, in modo da poter analizzare nel seguito le cause di questa malfunzione.

Ignorantemente non conscevo la possibilità di utilizzare in una stored procedure i blocchi try/cath, al fine di monitorare eventuali errori.

Chi si occupa di IT e di sicurezza in questi giorno ha avuto il suo bel daffare nel rispondere alle domande di molti utilizzatori di sistemi informativi terrorizzati di essere oggetto di un attacco da parte di Wannacry.

Grazie al cielo per la maggior parte delle volte si è trattato solo di questo: l'Italia questa volta ha subito questo nuova infezione in modo assolutamente trascurabile.

L'estensione del fenomeno, comunque, è su scala mondiale, e i numeri dei sistemi infettati è talmente alto che da giorni i giornali ne parlano: per questo vorrei scriverne un poco sul mio blog analizzando alcuni aspetti che possono essere sconosciuti a chi non si occupa giornalmente di IT.

Inziamo con il dire che wannacry fa parte della tipologia di virus chiamati ransomware: questa tipologia di attacco (che molti esperti affermano non far parte propriamente della categoria virus) nella pratica cripta i file e li rende inutilizzabili. Altri nomi dello stesso virus sono WannaCrypt WanaCrypt0r e Wanna Decryptor.

La genesi dell'attacco è il seguente.

Una mail o un messaggio spedito in chat dotato di un allegato in grado di diffondere questo attacco viene inviata a un destinatario che, in modo improvvido, apre l'allegato stesso. Questo file di solito ha l'aspetto di un normale documento pdf o anche excel, e nulla di nulla fa presagire il suo contenuto malevolo: in realtà, però, contiene un codice eseguibile capace di eseguire l'infezione.

Quindi quando si apre questo allegato in modo silente il codice prende possesso di tutti i file che possono essere raggiungibili dalla macchina (sia locali che posti sulle share di rete) e li cripta in modo da renderli inutilizzabili.

Come noto in Sql Server le stored procedure possono essere scritte usando codice .Net, tramite l'ausilio della Sql Server CLR Integration.

In questo post esporrò la procedura pratica passo-passo per creare una stored procedure in C#, e utilizzando le funzionalità di Visual Studio 2017 che permettono di raggiungere l'obbiettivo in modo facile e intuitivo.

Quanto scritto vale perfettamente e identicamente (si può dire ?) anche per Visual Studio 2015.

Premessa

Non so Voi, ma a me spesso riesce difficile scrivere alcune stored procedure direttamente in T-SQL: infatto SQL è un linguaggio prettamente dichiarativo, e a volte molte elaborazioni necessarie per estrarre dati richiedono procedure prettamente procedurali.

Linguaggi dichiarativi->Sono linguaggi in cui si descrive il risultato che si vuole ottenere (T-SQL è uno di questi).

Linguaggi Procedurali->Si descrive come ottenere un risultato (C# per esempio).

Ora, come noto T-SQL permette anche di scrivere codice usando lo stile procedurale (vedi cursori, etc), ma per chi, come me, è abituato per il 90 % della sua giornata a usare C# e PHP, e quindi stili di programmazione prettamente procedurali, diventa difficile convincere il cervello a fare lo "switch" a codice dichiarativo.

Per tale motivo per qualche stored procedure particolarmente complessa non disdegno di usare la SQL CLR Integration, e quindi di scrivere stored procedure usando codice C#.

Devo osservare anche usare questo tipo di stored procedure può introdurre anche importanti benefici nelle perfomance: in alcune situazioni i tempi di esecuzione sono sensibilmente più brevi rispetto allo stesso codice scritto in T-Sql.

Fine Premessa (era inutile ??)

Il Common Language Runtime (CLR) è la base fondamentale di Microsoft .NET Framework ed è la parte delegata all'esecuzione di managed code ottentuta da linguaggi compatibili.

Sql Server si integra con il CLR usando la funzionalità CLR integration, che in sostanza si traduce nella possibilità di scrivere diversi elementi procedurali usando managed code, invece di T-Sql.

  • Stored procedures
  • Triggers
  • User-defined functions (UDF)
  • User-defined types
  • User-defined aggregates