Esame 70-536

[70-536, #33] Passato!

Igor Damiani — Wed, 26 Jul 2006 13:26:00 GMT

Innanzitutto chiedo scusa a tutti per essere stato così poco produttivo nella mia serie di post relativi all'esame 70-536. Purtroppo ho avuto francamente poca voglia di scrivere (e studiare), e quando l'ho fatto è stato nei rari momenti in cui mi sentivo ispirato. Ho studiato molto meno per questo esame, ma sono rimasto contento perchè se l'ho superato devo ringraziare soprattutto la mia esperienza.

L'unico rammarico è che avrei potuto prendere un punteggio nettamente superiore al 718/1000 che ho miseramente conquistato. Ho sfiorato i punteggi massimi in quasi tutte le categorie (Developing applications that use types and applications, Implementing service processes, threading and application domains in a .NET Framework application, Implementing serialization and input/output functionality in a .NET Framework application, Improving the security of .NET Framework applications by using the .NET Framework 2.0 security features, Implementing globalization, drawing and text manipulation functionality in a .NET Framework application), ma sono letteralmente caduto a picco nelle ultime due categorie rimaste (Embedding configuration, diagnostic, management and installation features into a .NET Framework application, Implementing interoperability, reflection and mailing functionality in a .NET Framework application). Se avrò voglia questa sera scansiono la parte del report e la metto on-line, così me la guarderò tutte le mattine e mi do le martellate sulla testa. Devo dire che più che la teoria studiata da MSDN, questa volta ho sfruttato molto tutto quello che ho imparato lavorando con .NET - un'esperienza molto maggiore rispetto all'ottobre scorso.

Comunque mi sento un pollo questa mattina, perchè me ne sarei potuto tornare a casa con un punteggio altissimo. Beh, insomma, pazienza, ormai è andata! Adesso non voglio più pensare ad esami per un bel pezzo, prima devo tornare ricaricato dalle vacanze che mi aspettano!

[70-536, #32] L'attributo DllImport nei dettagli

Igor Damiani — Mon, 12 Jun 2006 16:08:00 GMT

I parametri dell'attributo DllImport
Nell'ultimo post riguardante l'esame 70-536, abbiamo visto come utilizzare l'attributo DllImport per poter utilizzare una funzione esportata da una libreria unmanaged. Nella sua forma base, DllImport richiede un solo parametro: una stringa che contiene il nome del file DLL che esporta la funzione che ci interessa utilizzare nella nostra applicazione managed. L'ultima volta avevamo fatto un piccolo esempio, considerando la funzione GetTempPath, esportata da kernel32.dll. la dichiarazione nella nostra classe managedera:

[DllImport("kernel32.dll")]
private static extern uint GetTempPath(uint nBufferLength,
[Out] StringBuilder lpBuffer);

L'attributo DllImport può avere qualche parametro aggiuntivo. Ad esempio, nel codice qui sopra il nome della funzione GetTempPath corrisponde al nome della funzione contenuta in kernel32.dll. Se per qualche motivo il nome della funzione managed contenuta nel prototipo differisce dal nome della funzione contenuta nella libreria unmanaged, dobbiamo fornire al framework l'entrypoint corretto. Ad esempio:

[DllImport("kernel32.dll", EntryPoint = "GetTempPath")]
private static extern uint GetTemporaryPath(uint nBufferLength,
[Out] StringBuilder lpBuffer);

Il parametro EntryPoint di DllImport nella dichiarazione qui sopra dice semplicemente che il nome della funzione in managed code è GetTemporaryPath, che punta all'entrypoint GetTempPath della libreria kernel32.dll. Un secondo possibile parametro è CharSet, che riveste un'importanza fondamentale nel caso in cui dobbiamo lavorare con le stringhe: impostando questo parametro su CharSet.Auto, ci assicuriamo che le stringhe vengono passate correttamente dal mondo managed al mondo unmanaged, e viceversa. Per il marshaling, il CLR si basa sul sistema operativo su cui sta girando l'assembly.

Il default marshaling e l'attributo MarshalAsAttribute
Il default marshaling è il comportamento di default che .NET assume ogni volta che deve passare oggetti tra il mondo managed ed il mondo unmanaged. Tecnicamente, è espresso da una serie di tabelle che esprimono come un tipo managed viene convertito nel tipo unmanaged. Ad esempio, questa tabella considera i value-typed di .NET. Tener presente l'attributo MarshalAs, grazie al quale possiamo modificare questo comportamento, comunicando esplicitamente al CLR come effettuare il marshaling in un particolare frangente. Caso tipico sono le stringhe, che in base al tipo unmanaged (LPStr, BStr, LPWStr, etc.) possono subire il marshaling verso il contesto managed secondo diverse tipi di destinazione.

Fare il marshaling di strutture
Esiste una pagina su MSDN che descrive accuratamente questo scenario. Fino ad adesso, abbiamo trattato con tipi di dato semplici, ad esclusione delle stringhe dove abbiamo a che fare innanzitutto con il CharSet, in secondo luogo con stringhe a lunghezza fissa o variabile (dove quindi dobbiamo usare il tipo string oppure la classe StringBuilder).

Cosa succede se dobbiamo invece trasferire intere strutture dati? Ne dobbiamo fare ovviamente il marshaling, ma come? Dobbiamo capire essenzialmente che il codice del mondo managed ed il codice del mondo unmanaged formattano i dati in memoria in modo diverso. Dobbiamo trovare quindi una strada per dire al CLR di non mappare i dati in memoria come vorrebbe lui, ma di rispettare determinate logiche. Questa strada è disponibile, ancora una volta, con un attributo .NET dedicato: StructLayout. Questo attributo prende come parametro un valore dell'enum LayoutKind, che esprime la modalità con cui i campi della nostra struttura vengono mappati in memoria. I valori di questo enum più interessanti sono principalmente due:

Explicit: siamo noi che indichiamo al CLR come mappare (uno ad uno) i campi della struttura. Attraverso l'attributo FieldOffset, esprimiamo in bytes la posizione fisica di un campo all'interno di una classe o di una struttura. Questo vale ovviamente sia nel mondo managed, che in unmanaged.
Sequential: i campi vengono mappati in memoria sequenzialmente, nello stesso ordine con cui questi servono dal lato unmanaged della nostra applicazione. I campi possono essere non contigui

Funzioni di callback
In altri scenari serve una funzione di callback, ovvero una funzione scritta in managed code che viene eseguita al termine dell'esecuzione di una funzione unmanaged. In altre parole, dal nostro codice .NET eseguiamo una funzione nativa attraverso P/Invoke, la quale deve sapere cosa eseguire quando la sua esecuzione termina. In realtà, come vedremo fra poco, non è detto che la callback serva solamente al termine dell'esecuzione: la funzione unmanaged potrebbe utilizzare la callback quando necessario, magari per avvisare il mondo .NET. Anche in questo caso, possiamo fare riferimento a questa pagina su MSDN per maggiori dettagli. La tecnica consiste nell'utilizzare un delegate, che non è nient'altro che un puntatore a funzione in ambiente .NET. L'esempio su MSDN tratta un caso molto particolare: attraverso P/Invoke, utilizziamo la funzione EnumWindows, la quale richiede una callback, che viene eseguita ogni volta che la funzione unmanaged lo richiede. Come facciamo a capire quando una funzione unmanaged richiede una callback? Bisogna leggere con attenzione il prototipo della funzione stessa, perchè dal tipo e dal nome dei parametri possiamo arrivare a capirlo. Il prototipo C++ della funzione EnumWindows è il seguente:

BOOL EnumWindows(WNDENUMPROC lpEnumFunc, LPARAM lParam)

Ciò significa che se vogliamo usare questa funzione unmanaged dobbiamo semplicemente convertire il primo parametro in un delegate:

public delegate bool CallBack(int hwnd, int lParam);

e conseguente utilizzare questo delegate come funzione di callback.

[70-536, #31] P/Invoke e l'attributo DllImport

Igor Damiani — Wed, 07 Jun 2006 12:42:00 GMT

Introduzione
P/Invoke è l'abbreviazione di Platform Invoke e consiste nella capacità da parte del nostro managed code di utilizzare DLL di sistema ed eseguire le funzioni contenute. Ho trovato di grande comodità il sito www.pinvoke.net, che ci aiuta con una grande raccolta di tutte le librerie di sistema e come poterle importare in una classe managed per rendere accessibile da C#, VB.NET e da tutti gli altri linguaggi della famiglia .NET. Anche in questo caso, come nel mio ultimo post, abbiamo a che fare con una classe wrapper: sarà questa che il codice managed eseguirà. Tale classe deve essere decorata dall'attributo DllImport, specificando il nome del file DLL che si vuole utilizzare in questa chiamata. Il namespace di riferimento per tutto quello che riguarda P/Invoke è System.Runtime.InteropServices.

Una chiamata semplice a GetTempPath
La funzione GetTempPath è funzione contenuta nel file kernel32.dll di Windows. Partendo da questo presupposto, in C# possiamo dichiarare una classe statica PInvoke ed inserire un metodo definito così:

static class PInvoke
{
    [DllImport("kernel32.dll")]
    public static extern uint GetTempPath(uint nBufferLength,
       [Out] StringBuilder lpBuffer);
}

Il metodo è marcato come statico e come extern, che esplicita il fatto che il metodo è implementato esternamente rispetto all'assembly. Il secondo parametro è un oggetto StringBuilder che verrà restituito (notare la keyword out ) e conterrà il path per i files temporanei restituito dall'OS. Questo è un caso estremamente semplice. L'unica verrà difficoltà è alla fin fine mappare correttamente i tipi tra il mondo managed ed il mondo unmanaged. Per questo risorse on-line come www.pinvoke.net sono estremamente importanti ed utili, perchè hanno fatto gran parte del lavoro e ci basta copiare & incollare.

Torniamo a noi. Una volta dichiarata la classe ed il metodo, chiamarlo non è per nulla diverso a qualsiasi altro metodo statico scritto in C#.

StringBuilder bld = new StringBuilder();
PInvoke.GetTempPath(255, bld);
string tempPath = bld.ToString();

Quando ha senso usare P/Invoke? In primo luogo, quando una certa funzionalità non è esposta dal Framework . Ad esempio, la libreria kernel32.dll espone la funzione CopyFileEx, che però è direttamente utilizzabile da codice managed. P/Invoke è molto utile, ripeto, se vogliamo interagire con componenti COM che al contrario non sono disponibili in .NET. Questo articolo su CodeProject ad esempio dimostra come usare P/Invoke con Windows Media Player, cosa che può essere fatta tra l'altro con le tecniche viste ieri (ovvero aggiungere come riferimento il file WMP.dll ed accedere così all'object model).

Ovviamente P/Invoke non funziona solo con le librerie di sistema, ma con qualsiasi libreria COM scritta in C++, comprese quindi le nostre.

Usiamo P/Invoke, ma usiamolo pulito!
In alcune occasioni, P/Invoke è davvero necessario, per cui siamo obbligati per forza di cose a servirci delle sue potenzialità. Però dobbiamo pensare bene alle complicazioni ed agire di conseguenza.

Le Windows API ritornano le condizioni di errori come banali costanti. Questo è in netta contrapposizione con la logica delle Exception messa in campo da .NET e dal framework. Per ovviare a questo inconveniente, è opportuno costruire una classe wrapper che converta un HRESULT restituito da Windows nella Exception più opportuna. Questa classe wrapper può inoltre nascondere l'accesso al mondo unmanaged: in pratica, una best practice da applicare è rendere privata la dichiarazione del metodo extern e creare invece un metodo public di buffer che sarà quello che useremo realmente nel nostro codice.

Vediamo di applicare nel concreto queste best practices. Vogliamo sempre utilizzare la funzione API GetTempPath esportata dalla libreria kernel32.dll. Ho creato una classe PInvoke, il cui codice è:

sealed class PInvoke
{
    public static string GetTemporaryPath()
    {
        StringBuilder bld = new StringBuilder();
        uint ret =  GetTempPath(255, bld);
        return(bld.ToString());
    }

    [DllImport("kernel32.dll")]
    private static extern uint GetTempPath(uint nBufferLength,
       [Out] StringBuilder lpBuffer);
}

Ho riportato due metodi. Un metodo pubblico GetTemporaryPath, scritto completamente in codice managed. Un metodo privato GetTempPath che invece è extern, ed è in unmanaged code. Tale classe sarà accessibile dal chiamante solo attraverso il metodo pubblico, come è normale che sia. Questo modus operandi rende possibili alcune migliorie al codice che abbiamo scritto:

quando il Framework renderà eventualmente disponibile la funzionalità alla quale adesso accediamo attraverso P/Invoke, ci basterà modificare l'implementazione del metodo pubblico GetTemporaryPath ed il gioco è fatto.
così facendo, isoliamo tutto quello che riguarda P/Invoke. Questo ci permette di limitare le porzioni di codice interessate ad eventuali crash o a problemi dovuti ad Interop.
come dicevo prima (ed è domanda di esame) possiamo mascherare gli errori ritornati da Win32 in opportune exception. Nel codice qui sopra, per esempio, memorizza nella variabile ret di tipo uint il valore ritornato dalla chiamata: mi basterebbe implementare un costrutto switch per intercettare eventuali errori ed agire di conseguenza.

Come usare DllImport
L'attributo DllImport ci permette di indicare in quale libreria viene esportata una certa funzione. Questo attributo ha diverse proprietà importanti. EntryPoint ci permette di specificare il nome della funzione contenuta nella libreria, nel caso in cui il nome sia diverso rispetto a quello che indichiamo noi nella dichiarazione del metodo. CharSet va impostato su CharSet.Auto, e ha importanza solo se la funzione esportata utilizza le stringhe; questo permette al CLR di utilizzare il set di caratteri corretto in base all'OS su cui si sta eseguendo il codice.

[70-536, #30] Primi passi con il mondo Interop

Igor Damiani — Mon, 05 Jun 2006 14:32:00 GMT

Introduzione
Fino ad oggi abbiamo sempre discusso con un mondo completamente managed, ovvero il cui codice è scritto al 100% in linguaggi previsti dal FX (VB.NET e C# in primo luogo), e che quindi gira all'interno del CLR. Possiamo però andare oltre, e permettere al nostro codice di oltrepassare le normali barriere ed avere a che fare con il managed unmanaged, ovvero tutto quello che riguarda codice Win32, mondo COM e via dicendo.

Ovviamente, il fatto che sia possibile non vuol dire che sia una cosa semplice, nè tantomeno che siamo esenti da rischi. La difficoltà principale è saper mappare in memoria gli oggetti managed in modo tale che siano utilizzabili dalle funzioni native Win32, e viceversa. Tale operazione è nota con il termine di marshaling: vi rimando alla tabella in fondo a questo articolo per tutti i dettagli del caso. Oggi cominciamo con le cose più semplici: vediamo infatti come poter aggiungere ad un nostro progetto .NET un riferimento ad un componente COM, sia esso un OCX, una DLL ActiveX o una type library.

Un riferimento ai componenti di Microsoft Word
Il concetto che ruota a queste problematiche è che .NET crea una classe managed che il nostro codice utilizza come wrapper per tutte le chiamate al mondo unmanaged. Ad esempio, se apriamo un qualsiasi progetto .NET con Visual Studio 2005, clicchiamo con il pulsanto destro sul nome del progetto e selezioniamo la voce Add Reference, l'IDE ci propone una finestra di dialogo dalla quale possiamo selezionare qualsiasi cosa ci passi per la testa: oggetti .NET, oggetti COM, altri progetti inseriti nella nostra solution, e via dicendo. Il tab Browse ci permette di sfogliare il contenuto del nostro hard-disk alla ricerca di files DLL, TLB, OLB, OCX ed EXE che vogliamo mettere nei riferimenti del nostro progetto.

Supponiamo per esempio di voler interoperare con Microsoft Word all'interno della nostra applicazione. Una delle possibili soluzioni consiste nell'aggiungere come riferimento il file MSWORD.OLB, seguendo il procedimento indicato prima. Questa semplice operazione si traduce in:

la creazione di un nuovo assembly in managed code, ottenuto partendo dal file MSWORD.OLB
l'inserimento del nuovo assembly nella GAC
l'aggiunta del nuovo assembly come riferimento al nostro progetto .NET

Così facendo, otteniamo in tutto e per tutto un riferimento valido all'object model di Word, utilizzabile quindi direttamente nel nostro codice attraverso la classe wrapper. Tale wrapper viene inserito in un namespace dedicato, che va quindi referenziato tramite la solita using. Per esempio:

Microsoft.Office.Interop.Word.Application appWord =
new Microsoft.Office.Interop.Word.Application();
Document doc = appWord.Documents.Open( /*Parametri*/ );

Il metodo Open esposto dall'oggetto Documents richiede un gran numero di parametri obbligatori, cosa che invece non accade per esempio quando facciamo la stessa con VB6. Il motivo è che molti dei parametri sono opzionali: in .NET questo comportamento si attua sfruttando l'overloading dei metodi. Questo esempio vale solo a scopo didattico, per cui ho deciso comunque di mantenerlo.

Il tool Tlbimp.exe
Il meccanismo di creazione della classe wrapper in managed code è disponibile anche attraverso il tool tlbimp.exe fornito dal FX2.0. Questo tool richiede essenzialmente il nome del file DLL di cui si vuole creare il wrapper. Rispetto alle funzionalità esposte dall'IDE, abbiamo diverse marce in più:

l'opzione /namespace: permette di specificare il namespace attraverso il quale sarà possibile raggiungere la nuova classe wrapper
l'opzione /out: permette di specificare il nome del file generato
l'opzione /keyfile: permette di specificare un file SNK per firmare con uno strong name l'assembly (tale file viene generato dal tool sn.exe, cliccare qui per maggiori informazioni)

Questo tool, quindi, permette di generare la classe wrapper al di fuori dell'IDE ed in modo completamente indipendente. L'unico parametro davvero necessario è il nome del file (tlbFile), che deve contenere obbligatoriamente una COM type library.

Compilare un progetto che fa uso di Interop
Esiste una pagina su MSDN che descrive come compilare un progetto .NET che usa InterOp per interagire con il mondo unmanaged. Se compiliamo dall'IDE, non cambia nulla: la classe wrapper nasconde il mondo unmanaged e siamo a posto. Se compiliamo da command-line, assicuriamoci di utilizzare il parametro /reference: del compilatore per referenziare l'assembly contenente la classe wrapper che ci serve.

Deploy di un'applicazione che fa uso di InterOp
Se stiamo facendo il deploy di un'applicazione InterOp, dobbiamo considerare se i nostri assembly wrapper devono essere condivisi fra più applicazioni. La pagina dedicata su MSDN è piuttosto chiara. Se gli assembly wrapper sono condivisi, vale la pena firmarli con uno strong name, inserirli nella GAC (che alla fin fine è un centralized repository fatto apposta per questo scopo) ed il gioco è fatto. Se gli assembly sono privati per una certa applicazione, il deploy deve essere fatto nella stessa directory dove si trova l'applicazione.

Dietro le quinte: come fa Tlbimp a convertire?
A partire da questa pagina su MSDN, vengono descritte quali sono le logiche che Tlbimp.exe mette in campo per convertire dal mondo COM al mondo managed. Si parla quindi di Imported Member Conversion, Imported Library Conversion, Imported Module Conversion e via dicendo.

Manca un mese al mio esame 70-536

Igor Damiani — Sun, 04 Jun 2006 23:42:00 GMT

In molti, giustamente, mi hanno detto che i miei post per l'esame 70-536 sono più discontinui rispetto alla mia prima serie per l'esame 70-316. Effettivamente, i miei impegni di lavoro mi hanno portato via più tempo del previsto e anche se trovo il tempo per studiare un po' (ho giusto giusto del materiale su P/Invoke che mi aspetta sul letto), ho sicuramente meno tempo per dedicarmi alla scrittura di post.

Spero davvero di poter riprendere a parlare come una volta, perlomeno sugli argomenti più importanti come P/Invoke che citavo prima. Rimane da vedere qualcosa sulla sicurezza ed altro ancora: avevo fissato l'esame il 1° Giugno, ma ho dovuto per forza spostarlo in là di un mese per essere sicuro di studiare tutto e per bene. Tra l'altro, non avere software di self-test come i Boson che avevo usato per il 70-316, mi incita ad arrivare più preparato rispetto al solito. Sperem...

[70-536, #29] Qualche dettaglio in più sulla gestione dei thread

Igor Damiani — Thu, 04 May 2006 11:19:00 GMT

Introduzione
Nel post precedente abbiamo visto come utilizzare la classe Thread in modo basilare. In breve: come creare un nuovo thread, utilizzando le classi ThreadStart e ParameterizedThreadStart, a seconda del fatto che il metodo da eseguire in modo asincrono abbiamo parametri oppure no.

Quello che vediamo oggi va un po' più in là. Sarà un po' tutto teorico, perchè francamente non ho mai avuto bisogno di scendere così nel dettaglio. Innanzitutto il Framework ci mette a disposizione la classe ThreadPool. Questa classe è definita come static, di conseguenza non abbiamo bisogno di istanziarla per poterla utilizzare. Come dice la pagina su MSDN, la classe ThreadPooo...

Provides a pool of threads that can be used to post work items, process asynchronous I/O, wait on behalf of other threads, and process timers.

Direi che è tutto abbastanza chiaro. Attraverso il metodo QueueUserWorkItem, possiamo richiedere al pool di thread la creazione di un nuovo thread che - ovviamente - giri in modo asincrono. Tutti i thread gestiti all'interno di ThreadPool hanno la property IsBackground = true. Una cosa importante da sottolineare è che la chiamata al metodo QueueUserWorkItem ritorna true se il thread è stato accodato al pool, oppure false se qualcosa non è andato bene (in tal caso, verrà sollevata un eccezione di tipo ApplicationException). Il metodo specificato nel costruttore inoltre non viene eseguito immediatamente, ma viene eseguito quando diventa disponibile il pool.

Nell'ultimo post avevo parlato di un'applicazione creata apposta per studiare questo argomento. In questa applicazione avevo implementato un semplice metodo aggiungiRecord per inserire qualche migliaio di record dentro una tabella di SQL Server, e lo avevo fatto girare in modo asincrono facendomi avvisare alla fine. Vediamo come ottenere lo stesso risultato con il pool di thread.

WaitCallback clk = new WaitCallback(aggiungiRecord);
bool ret = ThreadPool.QueueUserWorkItem(new WaitCallback(aggiungiRecord));

Il codice qui sopra istanzia un oggetto WaitCallback, da usare nella chiamata al metodo QueueUserWorkItem. La classe WaitCallback espone due proprietà interessanti: Method e Target. La prima è un'istanza della classe MethodInfo che ci permette (tramite Reflection) di analizzare a run-time il metodo che sta per essere eseguito in modo asincrono nel ThreadPool. La seconda proprietà invece è un riferimento all'object nel quale ci troviamo: nel mio caso, trattandosi di un Button, tale object è la Windows Forms relativa.
La seconda riga di codice non fa altro che richiedere l'inserimento all'interno del ThreadPool dell'oggetto WaitCallback. Salvo il risultato in una variabile bool per controllare che tutto sia andato regolarmente.

Metodi interessanti del ThreadPool
La classe ThreadPool espone alcuni metodi interessanti. Il metodo GetAvaiableThreads ritorna il numero di thread disponibili all'interno del thread. Esiste un pool di thread per ogni processo. Per default, il numero di thread disponibili per ogni pool è 25. E' possibile cambiare il numero di thread attraverso i metodi SetMaxThreads e SetMinThreads.

Mi sento di consigliare inoltre la lettura di questo articolo su MSDN che tratta in modo esauriente questo argomento.

Ho fissato la data dell'esame

Igor Damiani — Thu, 27 Apr 2006 19:27:00 GMT

Il 1° Giugno, alle ore 10:00, andrò a sostenere l'esame 70-536. In tempo per riprendere a lavorare, per ripassare un po' di roba, per vedere le cose che mancano, per farmi venire un po' d'ansia.

E, credetemi, se lo passo, io salto dalla gioia, e ve lo dico anche, alla faccia delle polemiche che ogni tanto imperversano sul blog. Su questo discorso, mi allineo con Lorenzo, sinceramente: quando posto sul mio blog, so di rivolgermi ad un mio gruppo di amici e quindi mi viene naturale raccontare le cose che mi succedono, sia belle che brutte. Tra queste cose, ci sono anche i miei esami, per cui...Posso però capire chi magari ha fallito un esame, e sente gli altri che magari lo passano...

Che dire...che il byte sia con me, e con tutti voi.

[70-536, #28] Esecuzione asincrona? Thread!

Igor Damiani — Thu, 27 Apr 2006 19:01:00 GMT

Ve l'avevo promesso che avrei ricominciato. Dopo questa lunga pausa, dovuta un po' a motivi di lavoro e salute, vediamo oggi di riprendere la mia serie di post per l'esame 70-536.

Questa ripresa dei lavori vede come protagonista la class Thread ed affini, ovvero tutte quelle classi definite nel namespace System.Threading che ci permettono di eseguire operazioni in modo asincrono. Ne avevamo già parlato in passato quando avevamo trattato il nuovo componente BackgroundWorker: con nuovo, intendo con il FX2.0. Il BackgroundWorker internamente fa ovviamente uso di thread secondari, e risolve la maggior parte delle problematiche riguardanti la gestione della UI. Come sappiamo, infatti, non possiamo manipolare i controlli sulla Windows Forms al di fuori del thread che le ha create: se abbiamo un task che dura un po' di tempo, e vogliamo ogni tanto notificare qualcosa su una Label, per esempio, non possiamo farlo in modo diretto come faremmo di solito, ma dobbiamo avere qualche accorgimento in più. Il BackgroundWorker semplifica e gestisce direttamente questi accorgimenti.

Se abbiamo bisogno di qualcosa di più performante, oppure non abbiamo UI da gestire (magari stiamo sviluppando un web-services), possiamo lavorare con la classe Thread. Vediamo come.

Introduzione alla classe Thread
Non mi capita tutti i giorni di sviluppare software che abbiano bisogno di thread secondari. Per questo motivo, ho sviluppato una piccola applicazione di test. In pratica, una semplice Windows Forms che si connette ad un database SQL Server, chiede quanti record si vogliono inserire e poi comincia a lanciare INSERT INTO su una tabella. La tabella non è importante (ha un campo identity ed un varchar(50)): ci basta sapere che per aggiungere 20.000 records, ci metto circa 20 secondi.

All'interno della form, ho creato un metodo privato aggiungiRecord:

private void aggiungiRecord()
{
    // codice
    for (int cycle = 0; cycle <= 20000; cycle++)
    {
        msg = "Marca " + cycle.ToString();
        cmd.Parameters[0].Value = msg;
        cmd.ExecuteNonQuery();

        updateUI.BeginInvoke(msg, null, null);
    }
    // codice
}

Ho eliminato le parti di codice non interessanti. Sul click di un pulsante, vogliamo eseguire il metodo qui sopra in un thread separato, cosicchè questo comincia a fare 20.000 inserimenti senza interrompere il nostro lavoro. Oltre alla classe Thread vera e propria, abbiamo bisogno di una delle due classi: ThreadStart oppure ParameterizedThreadStart. La prima se il metodo che vogliamo eseguire non ha parametri di input (come nel nostro caso), la seconda se invece c'è qualche parametro.
Quindi, per esempio:

ThreadStart start = new ThreadStart(aggiungiRecord);
_th = new Thread(start);
_th.Start();

Questo è la tecnica assolutamente più semplice: al click del pulsante, il thread parte ed esegue il codice. Il thread non ha nome, non ha priorità. Se il metodo aggiungiRecord avesse un parametro, dobbiamo usare un altro modalità:

int howMany;
int.TryParse(txtHowManyRecords.Text, out howMany);

ParameterizedThreadStart start = new ParameterizedThreadStart(aggiungiRecord);
_th = new Thread(start);
_th.Start(howMany);

Ho aggiunto sulla form una TextBox chiamata txtHowManyRecords che l'utente può usare per esprimere quanti record vuole inserire in tabella. Utilizzo il metodo statico TryParse della classe int: il metodo ritorna un bool, e in howMany finisce il numero richiesto. Il thread viene inizializzato con la classe ParameterizedThreadStart: per farlo, ho dovuto ovviamente modificare la firma di aggiungiRecord in questo modo:

private void aggiungiRecord(object o)
{ }

Il thread sta girando...e allora?
Giunti a questo punto, il thread sta girando. Il thread secondario sta eseguendo il codice del metodo aggiungiRecord. Probabilmente, il ciclo for inserito occuperà gran parte del tempo. All'interno di questo ciclo, possiamo notificare sulla UI qualsiasi cosa all'utente, ma con le dovute attenzioni che - credo - esulano un po' dallo scopo di questo post. Basta giocherellare con delegate, con BeginInvoke, InvokeRequired e dintorni, ed il gioco è fatto. Personalmente, avevo studiato il capitolo 14 "Multithreaded User Interfaces" di "Windows Forms Programming in C#", scritto da Chris Sells: credo il miglior capitolo di quel libro.

Maggior controllo sul thread
La classe Thread ha alcune caratteristiche molto interessanti, che consentono al nostro codice di controllarla, magari via UI. Innanzitutto, il thread secondario può girare con una cultura differente da quella standard (proprietà CurrentCulture e CurrentUICulture). Possiamo dargli un nome (proprietà Name) e capire in quale stato si trova (ThreadState, che è un'enum). Possiamo usare il metodo Suspend per interrompere l'esecuzione e il metodo Resume per riprenderla. Il metodo Abort blocca del tutto l'esecuzione del thread.

Vedremo nel prossimo post qualche dettaglio in più, e il download dell'applicazione di esempio che ho creato.

[70-536, #27] Le classi Installer, InstallContext ed altre classi

Igor Damiani — Tue, 28 Mar 2006 17:46:00 GMT

Della classe Installer abbiamo già parlato molto tempo fa. Era il 27 settembre, e mi stavo preparando per l'esame 70-316. Quel giorno abbiamo visto come aggiungere alla nostra soluzione un nuovo progetto Class Library, come implementare una classe custom che eredita da Installer. Tale classe viene consumata da Windows Installer durante il setup della nostra applicazione. Possiamo in pratica fare l'overloading degli eventi che accadono durante il processo di installazione, quindi gestire manualmente la Commit, provocare il Rollback, e via dicendo. Ma non solo: ci eravamo spinti un po' più in là. Avevamo aggiunto Custom Dialog, richiedendo alcune informazioni all'utente, come il suo indirizzo e-mail, oppure altre informazioni più semplici tramite CheckButton o RadioButton. Se volete implementare qualcosa di simile, consiglio caldamente di vedere il mio vecchio post, perchè io stesso ho avuto qualche difficoltà che sono riuscito a risolvere consultando me stesso indietro nel tempo. Questo è un paradosso temporale, ma lascio che siano Doc e Marty a tirarmi fuori dai guai senza provocare qualche casino nello spazio-tempo.

In questo post, darò per assodate un sacco di cose, quelle cioè descritte nel post a cui mi riferivo più sopra. In questi giorni ho ripreso in mano l'argomento, perchè ho voluto preparare un setup un po' particolare al mio software di fatturazione. Quindi, mi sono complicato la vita, giusto per approfondire la questione. Nulla di trascendentale, sia chiaro, ma è comunque qualcosa di interessante. Vediamo perchè.

La classe InstallContext
Dal punto di vista prettamente teorico, la classe InstallContext ci fornisce informazioni sull'Installer corrente. Essa si trova nel namespace System.Configuration.Install. Involontariamente, ne abbiamo già parlato. Quando ad esempio overloadiamo l'evento Commit, possiamo scrivere quanto segue:

public override void Commit(System.Collections.IDictionary savedState)
{
    base.Commit(savedState);

    InstallContext ctx = this.Context;
    string db = ctx.Parameters["DB"];
    string cognomeNome = ctx.Parameters["COGNOME_NOME"];
    string provincia = ctx.Parameters["PROVINCIA"];
    string email = ctx.Parameters["EMAIL"];
}

Nel codice qui sopra, non facciamo altro che usare un'istanza di InstallContext, che ci permette di reperire le informazioni inserite dall'utente nella prima fase del setup. La proprietà Parameters serve proprio a questo: nell'esempio qui sopra, DB è un CheckButton (che può essere recuperato anche dal metodo IsParameterTrue), mentre le altre COGNOME_NOME, PROVINCIA ed EMAIL sono normali TextBox che l'utente ha inputato. L'istanza è ritornata dalla property Context della classe Installer, che rappresenta per l'appunto l'engine di Windows Installer che sta girando in questo momento. Interessante l'uso del metodo LogMessage che ci permette di scrivere sul file di log dedicato per questo setup, utile magari per capire cosa ha inserito l'utente e come si è comportato di conseguenza l'installer.

Altre classi che riguardano il setup
Il namespace System.Configuration.Install contiene altre classi, alcune interessanti, altre un po' meno. La classe ManagedInstaller, per esempio, non deve essere usata direttamente nei nostri Installer: fa parte integrante dell'engine del FX, e quindi viene utilizzata solo internamente. Stesso discorso per l'interfaccia IManagedInstaller.

La classe TransactedInstaller invece è più interessante. Essa permette di installare una serie di assembly in un'unica transazione: o tutto avviene con successo, oppure in presenza di qualche errore, il tutto viene rollbackato. Questa classe espone la proprietà Installers, a cui vanno aggiunti a mano gli installer che vogliamo inserire in transazione. Dal momento che non è inserita nell'esame 70-536, non ne parlerò, ma è interessante sapere che c'è e su che principio funziona. Date un'occhiata all'interfaccia esposta da questa classe e buona lettura!

Le classi AssemblyInstaller e ComponentInstaller ereditano entrambe da Installer. La prima, in particolare, ci permette di caricare un assembly - specificato attraverso il costruttore - e di far partire il setup contenuto. Ovviamente, l'assembly deve derivare da Installer. L'interfaccia esposta ci permette di fare tutto quanto necessario per agevolare il lavoro.

[70-536, #26] Punto della situazione e rallentamenti

Igor Damiani — Fri, 24 Mar 2006 18:33:00 GMT

Ultimamente ho un po' rallentato la pubblicazione dei miei post sull'esame 70-536. In questo periodo sono un po' stra-carico, in tutti i casi per motivi di lavoro. Ho impegni che riguardano il mio software di fatturazione, ho impegni con la società con la quale lavoro, ho impegni personali, etc. etc. Insomma, il tempo è davvero poco. Gli argomenti da affrontare per coprire tutta la Preparation Guide dell'esame per ottenere la MCPD : Windows Developer invece sono ancora tanti.

Bisogna parlare di Thread ed affini, bisogna parlare di ServiceBase e dintorni, qualche concetto teorico su Application Domain, la classe Configuration e le sue relative interfacce. Altri argomenti invece sono bene o male gli stessi già affrontati in passato per il 70-316: mi sto riferendo in particolare alla classe Installer (per customizzare il setup della nostra applicazione), le classi Debug e Trace e a qualcosa inerente la globalizzazione (CultureInfo, prima fra tutte, ad esempio). C'è molta carne al fuoco anche per quanto riguarda P/Invoke ed Interop, c'è tutta una parte dedicata al System.Drawing: Brush, Pen, Color, TextureBrush, Font, Graphics, Point, etc. etc. Altre cose invece le salterò a piedi uniti con un solo balzo senza pensarci troppo: le classi File, Directory, DriveInfo, Path, EventArgs. Non che non siano importanti, ma ritengo che se uno si vuole certificare, debba sapere il minimo necessario e, onestamente, preferisco approfondire altri argomenti più succulenti.

Nonostante io continui a studiare per conto mio, ho veramente poco tempo per aprire IMHO e scrivere i miei soliti post. Continuerò a scrivere, questo è ovvio, ma sicuramente sarò un po' più rallentato rispetto ai miei soliti ritmi con i quali vi ho "viziato" fino ad oggi. Pazienza!