MCAD

Da oggi sono ufficialmente l'MCP #3502269!!

Igor Damiani — Sat, 26 Nov 2005 13:25:00 GMT

Ieri sera, con molta sorpresa, ho ricevuto il mio Welcome Kit per essere diventato MCP! Sono molto contento, ho subito infilato la mia wallet card nel portafoglio e, giusto per fare il figo, la farò vedere a chiunque mi passi sotto il naso!

So che molti di voi magari essere MCP non è nulla, però per me è fonte di soddisfazione. In attesa, quando le acque si saranno calmate, di ricominciare a studiare per sostenere gli altri esami. Continuo a ricevere tutt'oggi molti commenti sui miei post relativi ad MCAD scritti durante il periodo di preparazione. Volevo ringraziare pubblicamente, senza fare nomi e cognomi, tutti quelli che mi fanno i complimenti per il lavoro che ho fatto. Per me è una gioia indescrivibile scoprire di essere stato di aiuto a qualcuno, nel mio piccolo. Molti mi scrivono dicendo che hanno superato l'esame 70-316 proprio usando i miei post come preparazione. Ripeto, sono molto contento e non nascondo un certo orgoglio.

MCAD: la grande saga, to be continued?

Igor Damiani — Mon, 24 Oct 2005 12:49:00 GMT

Dopo avervi annoiato con ben 49 post relativi a MCAD, dopo aver superato l'esame 70-316, adesso per me è tempo di ricominciare daccapo. No, no, state tranquilli, non ho intenzione di ripartire con [MCAD.1] (ma quasi quasi...), quanto piuttosto quello di considerare il prossimo esame da fare, e quindi di ricominciare a studiare.

Dato che punto a MCAD, le strade possibili sono fondamentalmente tre. In ordine di preferenza personale crescente, ecco gli esami che sto valutando.

Designing and Implementing Databases with Microsoft SQL Server™ 2000 Enterprise Edition (70-229) - Di certo non mi metto a studiare SQL Server 2000 adesso che sta uscendo il 2005. Sarebbe una pazzia.
Developing and Implementing Web Applications with Microsoft Visual C#™ .NET and Microsoft Visual Studio .NET (70-315) - L'esame che preferisco di meno: ormai io con il Web c'entro poco o nulla. Anche se ogni tanto sogno di fare qualcosa in ambito Web, ho più la testa e la concezione delle applicazioni per Windows classiche
Developing XML Web Services and Server Components with Microsoft Visual C# and the Microsoft .NET Framework (70-320) - Questo è quello che mi ispira di più. Mi sembra più coerente con quello che mi serve nel mio lavoro di sviluppatore, mi sembra più "tosto", più utile e quello che, a lungo andare, rende meglio.

Quindi, optando per il 70-320, sto cercando in giro informazioni, tipo una Study Guide da approfondire sulla base di quello che ho fatto con quella di Lorenzo ottenibile da cramsession.com. La cerco sia freeware, sia a pagamento: fino ad oggi, le ricerche sono un po' state vane, se non una pagina Web sul sito Microsoft di cui adesso non ho l'URL. Mi sembra un po' scarna, quindi cerco di meglio. Ieri in SMAU ho provato a dare un'occhiata a qualche libro che mi potesse dare qualche input, ma nulla da fare. Da buon ignorante, non ho nemmeno chiesto a qualcuno di UGI, che magari mi avrebbe consigliato qualcosa.

Beh, adesso seguo il consiglio di Corrado: lavoro, poi vi farò sapere qualcosa!

[MCAD.49] Il giorno del fatidico esame 70-316

Igor Damiani — Thu, 20 Oct 2005 13:39:00 GMT

Dopo quasi 50 post effettivi sul mio blog per la preparazione all'esame 70-316, questa mattina, finalmente, sono andato alla Global Knowledge Network, qui a Milano, per sostenere finalmente l'esame. Dovevo essere già sul posto alle 8:30, mezz'ora prima dell'esame. La pioggia ha rallentato la mia andatura, ma alla fin fine sono arrivato puntuale.

Entro, do la carta d'identità, firmo un foglio. Mi accompagnano davanti al PC, dove mi aspetta un software intitolato qualcosa tipo "Developing and Implementing Windows-based Applications with Microsoft Visual C# .NET and Microsoft Visual Studio .NET". Un consiglio: le tizie non sanno nulla del software, non sanno spiegare cosa fa e come funziona. Si tratta di una normale applicazione, se proprio avete voglia, provate il tutorial (sull'astronomia) che vi fa imparare cosa e come cliccare durante il test vero e proprio.

Poi, cominciano le domande. Confermo tutti i consigli che sono stati dati a me: fate le domande una ad una. Rispondete a tutte. Quelle più semplici e a quelle che considerate più difficili. Queste ultime marcatele, così ci potete tornare su alla fine. Consiglio anche i Transcender, che simulano veramente un vero esame. I Boson (che ho usato più spesso) vanno bene, ma sono comunque troppo semplici per i miei gusti.

Nella stanza ero da solo, mi hanno dato biro e foglio. Che bello essere da soli: ragiono meglio se mugugno a bassa voce. Ed è quello che ho fatto. Comunque sia, arrivo fino alla fine, riguardo le domande che avevo marcato. Ci ri-ragiono su, cambio la risposta se mi va, alla fine confermo tutto. Il momento in cui si risponde a "This is the end of your exam. Are you sure?" è angoscioso!

Alla fine, sullo schemo è apparso "Congratulations! Your score is 920!"

Non ci volevo credere! Ho tirato un sospiro di sollievo. Ho fatto tutte le risposte esatte in 4 categorie su 7. Nelle rimanenti ho raggiunto circa l'80%. Nessuno mi spiegherà mai abbastanza come ho fatto ad azzeccarle tutte nella categoria "Configuring and Securing a Windows-based Application". Mah!

Grazie a tutti per l'incoraggiamento, per i commenti nei miei post, per avermi spronato, per avermi corretto o consigliato. Da oggi sono MCP!

[MCAD.48] Velocemente, come creare un Control personalizzato

Igor Damiani — Wed, 19 Oct 2005 14:22:00 GMT

Come ho già avuto modo di dire precedentemente, ci sono diversi argomenti che ho tralasciato nella mia serie di articoli dedicati a MCAD. Uno di questi, la creazione di Windows Control, lo considero piuttosto importante (e, come al solito, piuttosto divertente), per cui ne parleremo oggi in modo magari un po' superficiale, ma più che sufficiente per superare l'esame 70-316.

Introduzione
Innanzitutto, cominciamo col dire che creare un controllo significa in altre parole implementare una classe che erediti da System.Windows.Forms.UserControl. Se utilizziamo l'editor Visual Studio .NET, possiamo cominciare un progetto Windows Control Library. L'editor ci propone in progettazione il classico Form Designer, ma con qualche differenza. In questo contesto non stiamo disegnando una WF, ma un Control, quindi non abbiamo ad esempio la barra del titolo ed altre caratteristiche proprie di una WF. Possiamo posizionare controlli, possiamo ancorarli, possiamo scrivere codice proprio come se stessimo implementando una form, quindi tenendo conto tutto quello che ci siamo detti negli articoli passati.

La grande differenza è che il controllo non vive di natura propria, ma deve venir ospitato in qualche container: nel più semplice dei casi, una Windows Form. Una volta compilato il progetto e generato l'assembly, possiamo aggiungerne l'icona nella ToolBox dell'IDE di VS.NET. Come? Abbiamo due possibilità:

Clicchiamo con il pulsante destro, poi su "Add/Remove Items...", clicchiamo sul pulsante Browse e andiamo a selezionare l'assembly nella directory bin\Debug o bin\Release
Stessa procedura, ma cominciando dal menù Tools dell'IDE

Quando l'icona è stata aggiunta nella ToolBox, il nostro controllo è a nostra completa disposizione. Io personalmente ho preferito aggiungere un nuovo progetto Windows Application alla soluzione corrente. In questo modo passo velocemente dal progetto Control al progetto che ospita il Control stesso. Più comodo di così!

Property personalizzate del nostro Control
Come tutte le classi, anche i Control possiedono properties che possono influenzarne il comportamento. Alcune di queste properties vengono ereditate dalla classe UserControl, altre ovviamente possiamo definirle noi a nostro piacimento in base alle necessità. Chi sviluppa con .NET da un po' di tempo, può sembrare normale, ma chi proviene da VB6, per esempio, troverà anche una piccola sorpresa. Mi spiego meglio.

Le property personalizzate appaiono automaticamente nella Property Window nel progetto in cui viene ospitato il Control stesso. Non solo: l'IDE è anche abbastanza intelligente: se la nostra property è definibile attraverso un public enum, allora nella Property Window comparirà la ComboBox che ci permette di dare un valore alla property semplicemente scegliendola tra i possibili valori. Ad esempio, se il mio Control possiede una property di tipo DrawingModeStyle che è un enum:

public enum DrawingModeStyle
{
    Happy = 0,
    Sad = 1,
    Angry = 2
}

Quando andrò a selezionare il Control sulla mia WF, la Property Windows mostrerà una cosa del genere:

Chi ha partecipato al Workshop di Luglio, sa benissimo come adattare la Property Windows ai nostri scopi. Usando gli attributi [Category], [Description], [Browseable] e tanti altri, possiamo regolare la nostra property DrawingMode come vogliamo.

Disegnare un nostro Control da zero
Questo è il caso più semplice, ovvero la costruzione di un Control "complesso" che comprende più Control e ne estende le funzionalità. .NET ci dà la possibilità di disegnare un controllo completamente da zero, usando tutte le classi incluse nel namespace System.Drawing. Il succo del discorso è quello di fare l'override dell'evento Paint del controllo di base, e disegnare quello che vogliamo.

Farò in tempo a parlarne meglio in un altro post?

[MCAD.47] Data-Binding: in mezzo fra Control e sorgente dati

Igor Damiani — Fri, 07 Oct 2005 14:22:00 GMT

Usare il data-binding può veramente togliere gran parte del lavoro di scrittura del codice. In questi giorni lo sto esplorando ben bene, e devo dire che, sebbene ci siano molti modi diversi e sicuramente più ottimizzati per realizzare WF che prelevino i dati da un database, è veramente divertente e piacevole vedere cosa si può fare in così poco tempo. Si è sul serio molto più produttivi.

Non mi interessa parlare di DataSource, DataMember ed affini. In parte l'ho già fatto nel mio post precedente , in parte vorrei invece approfondire un discorso che, ancora una volta, mi ha colpito positivamente. Ovvero, parlare della classe Binding, che è una sorte di "ponte" che si trova a metà strada tra il nostro Control e la sorgente dati sottostante. Usando la classe Binding, infatti, possiamo intervenire nel momento in cui .NET fa il binding vero e proprio, e giocare come vogliamo. Vediamo un po' più nel dettaglio cosa intendo.

Qual'è lo scopo della classe Binding? A cosa serve?
Abbiamo detto che la classe Binding è il motore nascosto che fa muovere tutto il data-binding delle nostre WF. Quando chiamiamo il metodo Add della property DataBindings di un qualsiasi controllo, in realtà creiamo implicitamente un'istanza della classe Binding. Possiamo poi recuperarla accedendo alla collection DataBindings del relativo controllo, come ad esempio qui sotto, tratto da un'applicazione che sto creando proprio in questi giorni:

// recupero Binding accedendo alla collection DataBindings
Binding bnd = this.txtDenominazione.DataBindings["Text"];

La classe Binding espone, tra le altre cose, di due eventi importanti ed utili: Format e Parse. Il Format si scatena ogni volta che un'informazione viene formattata su un controllo. Il Parse si scatena ogni volta che un'informazione viene editata sul controllo ed aggiornata nella sorgente dati. E' sufficiente aggiungere un delegate per questi due eventi per manipolare a piacimento quello che "va e che viene, da e verso la sorgente dati". Ad esempio, banalmente:

Binding bnd = this.txtDenominazione.DataBindings["Text"];
bnd.Format += new ConvertEventHandler(formatta);
.
...

private void formatta(object sender, ConvertEventArgs e)
{ e.Value = e.Value.ToString().ToUpper(); }

Se dalla sorgente dati leggo la stringa "via giovanni pascoli, 14", nella mia TextBox apparirà "VIA GIOVANNI PASCOLI", proprio perchè l'evento Format si frappone. In questo caso, ho messo un semplice ToUpper() per convertire tutto maiuscolo: avremmo potuto fare qualsiasi altra cosa, nei limiti del framework (!). Stessa cosa all'inverso, possiamo gestire l'evento Parse per restituire alla sorgente dati l'informazione come vogliamo che venga scritta nel database.

Utilizzo avanzato del data-binding
Usando questa tecnica, ho fatto una cosa più che divertente.
Ho creato una piccola tabella ForBind su SQL Server con un solo campo DimFont di tipo int. Ho creato record a caso con i valori: 24, 16, 36, 6, etc. Ho cominciato un progetto WF nuovo, ho usato la toolbox per creare velocemente SqlConnection, SqlDataAdapter e un DataSet per caricare il contenuto della tabella ForBind.

Poi, ho creato (via codice, questa volta), un binding su una TextBox della mia WF tra la property Font e il campo DimFont. Ovviamente, compilando il progetto ed eseguendolo, ho avuto un exception. E' importante ricordare che se faccio il binding su una property di tipo xyz (int, string, Font, size e così via), la sorgente dati deve in qualche modo ritornare un oggetto dello stesso tipo. Tenendo a mente questo, ho scritto un piccolo handler dell'evento Format in questo modo:

private void formattaFont(object sender, ConvertEventArgs e)
{
int dim = (int) e.Value;
e.Value = new Font("Tahoma", dim);
}

L'evento, come abbiamo visto, viene sollevato prima che la sorgente dati comunichi con il Control. Intercettiamo la chiamata, restituiamo un oggetto Font. Adesso, se eseguo il progetto, la TextBox usa un Font piuttosto che un altro in base alla posizione del record su cui sono posizionato all'interno della sorgente dati (ho aggiunto due Button per sfogliare in back e in forward passando per il BindingManagerBase).

Con la property Font magari ha poco senso: immaginatevi però che bello "bindare" il BackColor, o la Size o altre property che all'occasione posso rivelarsi utili

[MCAD.46] Velocemente, il data-binding

Igor Damiani — Wed, 05 Oct 2005 16:35:00 GMT

Faccio sempre una brutta faccia quando sento parlare di data-binding.
In ambiente Visual Basic 6 ed affini, il data-binding è un metodo che permette di "collegare" bidirezionalmente un controllo ad una sorgente dati come, tipicamente, un database. Questo collegamento era completamente trasparente per l'utente: era sufficiente posizionare un controllo Data sul form o, più recentemente, un ADODC e impostare qualche proprietà del controllo ed il gioco era fatto. Troppi automatismi rendono il vita facile, è vero, ma tolgono allo stesso tempo controllo lasciando poco spazio al programmatore per intervenire nel processo che, di fatto, era gestito dal runtime di VB.

In ambiente .NET le cose sono radicalmente diverse. Data l'architettura disconnessa di ADO.NET, non siamo mai veramente connessi al database, se non durante l'operazione di Fill attuata dal SqlDataAdapter. Di conseguenza, il data-binding in .NET permette, come prima, di collegare un controllo ad una sorgente dati, ma nel significato più ampio e generico del termine. Una sorgente dati infatti può essere una banale variabile, una classe, una collection o, nei casi più utili, una DataTable o un DataSet. Non solo: se prima con VB6 il controllo era legato alla sorgente dati tramite la proprietà stabilita a priori dal creatore del controllo, con .NET è tutto sotto il nostro controllo.
Vediamo, velocemente, come, cosa, perchè e quando!

Colleghiamo una ListBox con una sorgente dati
Ho fatto una prova veloce, semplice e, meraviglia, funzionante. Ho preso una WF, ho posizionato una banale ListBox, ho creato un ArrayList con un po' di elementi a caso. Poi, ho legato la ListBox con l'ArrayList. Il tutto con una manciata di righe di codice C#:

lista = new ArrayList();
for(int i=1;i<11;i++)
lista.Add("elemento n." + i);
this.listBox1.DataSource = lista;

Il codice qui sopra popola l'ArrayList lista (definito come private della WF) con 10 stringhe. Al termine dell'esecuzione del codice qui sopra, la ListBox mostra tutti gli elementi di lista. Questo automatismo è fornito gratis dal framework: se un Control possiede le properties DataSource e/o DataMember, possiamo impostarne la sorgente dati. Questo è il caso più semplice, perchè il Control è sufficientemente intelligente da conoscere come mostrare i dati: se è un Control di tipo lista, allora semplicemente mostrerà tutti gli elementi. Così è per esempio per la ListBox o per la ComboBox.

Se parliamo di data-binding, la DataGrid gioca un ruolo fondamentale. Essa possiede le properties DataSource e DataMember, per cui possiamo riempirla di dati molto velocemente tramite un bel DataSet riempito a dovere, tramite:

this.grdGriglia.DataSource = dsTabella;

Nulla di più semplice. Come ben sappiamo però, un DataSet può contenere più di una tabella: se vogliamo mostrare direttamente il contenuto di una DataTable specifica, possiamo farlo agendo su DataMember, che va impostato sul nome della tabella stessa. La DataGrid dispone di diverse caratteristiche comode, come la possibilità di ordinare i records agendo sugli headers della griglia.

Io mi sono divertito ad impostare un DataView come DataSource della griglia. Il DataView rappresenta una vista su una DataTable specifica. Usandolo, ho usato le proprietà Sort e RowFilter per riordinare la griglia come volevo, o per filtrarne i dati.

Fare data-binding su una TextBox
Complichiamoci la vita. La TextBox non dispone di DataSource e DataMember, però possiamo comunque fare binding in modo interessante utilizzando la property DataBindings. Questa property è in realtà una collection di oggetti Binding che consente di creare un collegamento (come dicevo prima) tra controllo e sorgente dati indicando: property del controllo, nome della sorgente ed eventuale campo della sorgente dati. Ultima nota: trattandosi di una TextBox, vedremo un solo elemento alla volta della sorgente dati. Il caso più semplice e banale (leggere inutile) è questo:

string testo = "pippo";
Binding bnd = new Binding("Text", testo, null);
this.textBox1.DataBindings.Add(bnd);

Nonostante la semplicità, possiamo già dedurre una cosa importante. La variabile testo può essere qualsiasi contenitore di dati, e null è il nome della property del contenitore. Per esempio, ho creato una classe Auto con tre proprietà: marca, modello e numero di porte. Ho creato una property GetCompleteName che mi ritorna una string formata dalla concatenazione di marca + modello. Ho fatto un semplice data binding con le seguenti linee di codice:

Auto mia = new Auto("Opel", "Astra 1.6", 4);
Binding bnd = new Binding("Text", mia, "GetCompleteName");
this.textBox1.DataBindings.Add(bnd);

Quando avvio il progetto, la TextBox contiene la string "Opel Astra 1.6". Con le righe qui sopra, ho collegato la property Text della TextBox con la property GetCompleteName della mia classe Auto. Attenzione che GetCompleteName deve essere implementata come una property (keyword get) e non come metodo: il binding in quest'ultimo caso non funziona.

Lasciatemi fare qualche esperimento interessante, e proseguirò sul discorso data-binding.
Tutti i commenti del caso sono assolutamente graditi!!!

[MCAD.45] Reindirizzare un assembly da una oldVersion ad una newVersion

Igor Damiani — Tue, 04 Oct 2005 14:01:00 GMT

Ecco lo scenario: il vostro collega ha sviluppato in C# un assembly molto carino. L'assembly si chiama GetBirthday.dll e dispone di un solo metodo statico, GetNearestBirthday(). L'assembly è strong-named. Il nostro collega l'ha installato nella nostra GAC con un piccolo installer fatto da lui. Il metodo GetNearestBirthday ritorna una string contenente il compleanno più vicino nel tempo fra quelli presenti in un database SQL Server (qualsiasi riferimento all'applicazione Age è puramente casuale).

L'assembly installato in questo momento è alla versione 1.0.0.0: noi lo abbiamo usato nella nostra applicazione Age, e gira a meraviglia. Clicco un pulsante, e in una TextBox mi viene detto che il prossimo compleanno è di mio papà!!! Me lo devo ricodare...

Oggi il nostro collega ha preparato una nuova versione di GetBirthday.dll (la 1.1.0.0) con un nuovo metodo (che adesso è OT e non ci interessa). Ci prepara un nuovo installer, che noi prontamente eseguiamo. Lanciamo la nostra applicazione, ed otteniamo una bella exception all'avvio. Aiuto, e ADESSO? Abbiamo due strade:

Chiamiamo il nostro collega, gli facciamo vedere il problema, lo copriamo di insulti e nel frattempo noi siamo bloccati con il nostro lavoro perchè l'assembly blocca tutto
Chiamiamo il nostro collega, gli facciamo vedere il problema, lo copriamo di insulti e nel frattempo continuiamo tranquillamente a lavorare usando la versione precedente dell'assembly

Siccome siamo persone civili, propendiamo per la seconda opzione. Come facciamo? Il giochino sta nel lavorare sui files XML che .NET utilizza per gestire tutto l'ambiente di runtime del CLR. Facendola breve, apriamo il file Age.exe.config ed aggiungiamo il seguente blocco XML:

I tag <runtime></runtime> contengono tutte le informazioni che il runtime .NET userà per reindirizzare una versione di un assembly ad un altra. Nel nostro caso, specifichiamo che se la nostra applicazione vuole usare la versione 1.1.0.0 di GetBirthday (che è quella che ci dà errore), in realtà dovrà usare la 1.0.0.0 (che invece è quella che gira correttamente). Et voilà, il gioco è fatto!!!

Altre informazioni
Da notare che questo "giochino" di redirect è possibile solo se l'assembly è strong-named, perchè solo questi assembly hanno una release. Il CLR ignora di fatto la versione di un assembly che non è strong-named.

Il blocco XML indicato sopra può essere utilizzato anche nei files machine.config e web.config. Io personalmente ho avuto comunque qualche problema. Incollandolo nel mio machine.config, non mi partiva più IMHO (con un TypeInizializationException): perchè? In teoria IMHO non è nemmeno a conoscenza del mio assembly, perchè mi segnala questa exception?

[MCAD.44] Quello che secondo me ho trascurato nel mio MCAD

Igor Damiani — Tue, 04 Oct 2005 12:17:00 GMT

Questo è il post relativo a MCAD N°44, oggi è il 4 ottobre, il primo post è stato scritto il 4 luglio. Dev'essere il destino che ogni tanto fa questi giochini!! Oggi, quando uscirò dall'uffico, andrò nella prima ricevitoria a giocare i numeri 4 e 44, ambo secco. Chi lo sa, magari vinco qualcosa!!!

Tornando seri: ritengo di aver parlato della maggior parte degli argomenti inerenti l'esame 70-316. La data dell'esame si sta avvicinando. Cosa manca? Cosa ho trascurato? Cosa conviene leggersi e studiarsi per bene prima di affrontare il mitico primo esame per diventare MCP? Un'idea ce l'ho: usando i software Boson e provando anche i Transcender mi sono fatto un'idea piuttosto precisa, in base alle domande che mi hanno trovato spiazzato e con un'espressione sulla faccia del tipo: "Eeehhh??? Che diavolo è 'sta roba????".
Vediamo di parlarne brevemente.

Files config
Parecchie domande riguardavano machine.config e app.config. Ad esempio:

come obbligare un'applicazione ad usare un assembly alla versione XYZ piuttosto che un'altra
cosa devo fare per abilitare o disabilitare il trace dell'applicazione
qual'è il posto più conveniente per modificare questo o quel setting di quella applicazione

Utilizzo di Web Services
Come usare WSDL.exe per ottenere la classe proxy, oppure quali metodi contiene la classe proxy per invocare un ws in modo sincrono ed asincrono.

Utilizzo di XML
La classe XMLReader nel namespace System.Xml. Ricordarsi che c'è il metodo ExecuteXMLReader del SqlCommand che ritorna appunto un XMLReader.

Gli altri tools della command-line di .NET
Ricordarsi che TLBIMP.exe serve per far usare un componente scritto in managed code nel mondo COM (ad esempio, da C# al buon VB 6.0). REGASM.exe è l'opposto.

Classe data-binding e DataView
Uno dei prossimi post parlerà di data-binding e della classe DataView. Ho incontrato parecchie domande che chiedevano qual'è il modo più efficiente per filtrare righe e/o ricerche.

Indipendentemente dagli argomenti, ho trovato domande tranello. Se un'applicazione è installata sul server e gli utenti ci accedono tramite network share, sul mio PC non avrò mai un file di config: questo ragionamento spesso porta ad escludere 2 risposte su 4. Oppure, 30 righe per descrivere uno scenario, mentre poi la domanda è molto più banale.

Sulle domande relative al codice in sè non ho avuto grossissimi problemi: un po' l'esperienza personale, un po' il fatto di aver sviluppato una piccola applicazione, mi hanno aiutato. Le domande dei test sono di due tipi: tramite RadioButton (una sola è giusta, e bisogna trovarla), oppure tramite CheckBox. In quest'ultimo caso, ovviamente, le risposte sono più di una. Le più difficili (che a me piacciono tantissimo, però) sono quelle dove bisogna "fleggare" più di un CheckBox per selezionare le linee di codice corrette per fare una determinata cosa. Difficili, dicevo, ma veramente belle!

La data dell'esame è: STR((GG + MM + AAAA) + 4) & "2005"
dove GG = giorno del mio compleanno, MM = mese del mio compleanno, AAAA = anno di nascita
Notare che nella formula compare ancora il numero 4...sì, è deciso...è proprio il destino!
Chi lo sa, bene! Chi non lo sa, si arrangi.....o magari Google dice qualcosa???

[MCAD.43] La sicurezza basata sull'utente di Windows

Igor Damiani — Mon, 03 Oct 2005 13:41:00 GMT

Nei post [MCAD.31] e [MCAD.33] abbiamo visto come lavorare con .NET avendo a che fare con la CAS (Code Access Security ), ovvero come assegnare o revocare dei permessi in base all'origine e all' "affidabilità" del codice che sta per essere eseguito. In base all'URL di provenienza, a seconda che l'assembly venga eseguito dalle directory locali del proprio PC oppure dalla Intranet, il runtime .NET assegna un permission sets piuttosto che un altro. Abbiamo visto come usare caspol.exe oppure il tool analogo (Microsoft .NET Framework 1.1 Configuration) per amministrare i permessi in modo congruo con quello che ci interessa fare.

Esiste anche una seconda possibilità, identica a quella che veniva usata nell'era pre .NET. Ovvero, assegnare dei permessi in base all'utente attualmente loggato sul PC, oppure al suo gruppo di appartenenza. Questa logica viene implementata attraverso le classi WindowsIdentity e WindowsPrincipal: vediamo come usarle correttamente.

Come rilevare l'utente corrente ed il suo gruppo di appartenenza
Innanzitutto occorre dichiarare l'uso del namespace System.Security.Principal. Fatto questo, possiamo utilizzare le classi WindowsIdentity e WindowsPrincipal. La prima classe fa riferimento ad un Identity, ovvero ad uno user di Windows, mentre la seconda classe è utile perchè espone un metodo IsInRole che ci permette di capire se un certo utente appartiene ad un gruppo specifico passato come parametro.
Vediamo qualche riga di codice veloce veloce:

WindowsIdentity io = WindowsIdentity.GetCurrent();
StringBuilder testo = new StringBuilder(string.Empty);
testo.AppendFormat("Tipo di autenticazione : {0}; ", io.AuthenticationType);
testo.AppendFormat("Username : {0}; ", io.Name);
testo.AppendFormat("E' anonimo? : {0}; ", io.IsAnonymous);
testo.AppendFormat("E' autenticato? : {0}", io.IsAuthenticated);

Il metodo statico GetCurrent() ritorna un'istanza relativa all'utente correntemente loggato nel dominio. Mi sono divertito ad usare la classe StringBuilder per costruirmi una stringa da mostrare in una bella TextBox sul mio WF di prova. La property Name ritorna una stringa formattata come: DOMAIN\Username. Nel mio caso, sul mio PC di casa, mi ha ritornato "TERRA\Igor". Le altre property IsAnonymous e IsAuthenticated ritornano rispettivamente valori booleani che indicano se l'utente è anonimo (nel mio caso, false), e se l'utente è stato autenticato (per me true).

Già con queste property possiamo divertirci e adattare l'esecuzione del codice in modo opportuno. Per esempio, abilitare un MenuItem solo se lo username è "Admin". Tramite la classe WindowsPrincipal possiamo invece risalire al gruppo di appartenenza dell'utente stesso.

WindowsPrincipal prin = new WindowsPrincipal(io);
if (prin.IsInRole(WindowsBuiltInRole.Administrator))
testo.Append("; Fai parte degli Administrators!");

Il metodo IsInRole possiede 3 overload diversi: posso usare l'enum WindowsBuiltInRole (come nell'esempio qui sopra), posso usare un valore int (???) oppure, infine, posso usare una string . La chiamata al metodo IsInRole ritorna un valore boolean che ci dice se l'utente passato nel costruttore di WindowsPrincipal appartiene o meno al gruppo passato come parametro.

Il codice qui sopra mi dice se appartengo al gruppo degli Administrators: nel mio caso, sì. Purtroppo, non sono riuscito ad ottenere lo stesso risultato usando come parametro una string: ho provato "DOMINIO\Administrators", "DOMINIO\Administrator" e tutte le possibili varianti (usare il nome del PC al posto del dominio, per esempio), ma in tutti i casi mi ha sempre ritornato false.
Con l'enum WindowsBuiltInRole nessun problema: continuerò, se mi servirà, ad usare questo.

Sicuramente c'è ancora molto da dire, ma...
Quando si ha a che fare con la sicurezza delle applicazioni, c'è sempre molto da dire e molto da imparare. Se siccome il giorno dell'esame si avvicina, chiudo qua il discorso.

I prossimi post saranno più che altro mirati a parlare degli argomenti "minori" che ho tralasciato, come i files *.config (che odio, non sopporto e, ne sono certo, all'esame mi fregheranno) ed alcuni tools della command-line come tlbimp.exe ed affini. Qualsiasi suggerimento è, come al solito, ben accetto!
Alla prossima...

[MCAD.42] Lo sapevate che...alcune piccole chicche...

Igor Damiani — Thu, 29 Sep 2005 12:55:00 GMT

La classe SqlCommand dispone del metodo Prepare per ottimizzarne l'esecuzione?
E che prima di chiamarlo dobbiamo settare i data-type di tutti i parametri, soprattutto la proprietà Size per tutti quei parametri che hanno una lunghezza variabile?

Esiste la keywork checked che serve a controllare gli overflow nelle espressioni?

Esiste la keyword using che serve (anche) ad iniziare blocchi di codice al termine dei quali viene fatta automaticamente la Dispose dell'oggetto indicato al momento della sua dichiarazione?

Lo strumento più corretto per distribuire un assembly nella GAC di un cliente non è gacutil, ma Windows Installer! Perchè? Perchè gacutil non incrementa il reference counter dell'assembly: gacutil va usato solo in ambiente di sviluppo, mentre Windows Installer in tutti gli altri casi.

Esiste un metodo della classe String che ritorna un boolean che dice se la stringa stessa termina con una stringa passata come parametro? Il metodo in questione si chiama EndsWith.

Esiste la property MdiList del MenuItem che, se messa a true, permette di popolare un menù con tutte le finestre contenute nel form MDI.

Come faccio a far comparire una Windows Form nel punto indicato dalla sua property Location? Oltre a specificare Location, devo impostare StartPosition = Manual.

Posso creare via codice un ContextMenu uguale a quello di un MainMenu, usando il metodo CloneMenu applicato sul MainMenu che ci interessa duplicare.

La classe System.Windows.Forms.Form deriva dalla classe ControlContainer.

Un oggetto viene definito stateful quando mantiene il suo stato interno tra una chiamata ad un metodo ed un'altra. Questo in contrapposizione a stateless.

Posso decorare un metodo con la classe DebuggerStepThrough per dire al debugger di non entrare nel metodo stesso. Posso comunque inserire breakpoints, ma non ci arriverò mai.