In questo periodo sto facendo molta consulenza per aziende italiane alle prese con la migrazione da VB6, usando ovviamente la versione preliminare di VB Migration Partner. Oramai la beta è stabile e si comporta davvero molto bene. In un solo giorno, ad esempio, abbiamo migrato una applicazione di circa 20mila righe che lavora in modo intensivo con ADO in circa mezza giornata, e tutto funziona a meraviglia!

Anche se la migrazione sta andando bene, a volte i programmi migrati sono più lenti del codice VB6 originario. Per esperienza le cause sono principalmente due: (1) l'uso di COM Interop per accedere agli oggetti ADO, (2) un uso massiccio di concatenazione di stringhe. Per il primo problema non c'è molto da fare, purtroppo: occorre migrare il codice di accesso al database da ADO a ADO.NET, un compito più semplice a dirsi che a farsi. Per il secondo problema ci sarebbe invece una soluzione semplice: basterebbe sostituire la variabile stringa con una variabile StringBuilder, e le concatenazioni sarebbero automaticamente più veloci. Peccato che questa sostituzione comporti una revisione completa del codice, perchè richiede di trasformare tutti gli operatori & (concatenazione) con il metodo Append, per non parlare dei casi in cui la variabile stringa viene usata come argomento a funzioni come Trim o Left. Ad esempio, il seguente codice richiede ben 17 secondi sul mio sistema a 3GHz:

Dim s As String = ""
Dim sw As Stopwatch = Stopwatch.StartNew()
For i As Integer = 1 To 100000
    s = s + "*"
Next
MsgBox(sw.Elapsed.ToString)

Per fortuna la soluzione è davvero semplice: basta creare una classe che utilizzi internamente un oggetto StringBuilder, che ridefinisca gli operatori & e +, e che supporti la conversione implicita da-a stringa. Il codice di questa classe StringBuilder6 si scrive davvero in pochi minuti:

Imports System.Text

Public Class StringBuilder6

    Private buffer As New StringBuilder

    ' return the inner string

    Public Overrides Function ToString() As String
        Return buffer.ToString()
    End Function

    Public Shared Operator +(ByVal op1 As StringBuilder6, ByVal op2 As String) As StringBuilder6
        op1.buffer.Append(op2)
        Return op1
    End Operator

    Public Shared Operator &(ByVal op1 As StringBuilder6, ByVal op2 As String) As StringBuilder6
        op1.buffer.Append(op2)
        Return op1
    End Operator

    ' convert to string

    Public Shared Widening Operator CType(ByVal op As StringBuilder6) As String
        Return op.ToString()
    End Operator

    ' convert from string

    Public Shared Widening Operator CType(ByVal str As String) As StringBuilder6
        Dim op As New StringBuilder6()
        op.buffer.Append(str)
        Return op
    End Operator

End Class

A questo punto per velocizzare il codice visto prima è sufficiente modificare UNA SOLA ISTRUZIONE, ovvero la dichiarazione della variabile stringa:

Dim s As StringBuilder6 = ""

Premessa. Non so se questa piccola scoperta che ho fatto di recente sia già documentata da qualche parte su Internet. Non ne ho mai sentito parlare, ma mi sembra strano che nessun’altro ci abbia pensato prima. Comunque, ci sono arrivato da solo e questo è sufficiente per scriverne sul blog.

Mi sembra inutile rimarcare il fatto che uno dei problemi che assilla chi scrive software per professione è la protezione dalle copie. In più, se programmate con .NET avete anche il problema di proteggere le applicazioni dalla decompilazione. Ovviamente i due problemi sono collegati, perchè se volete proteggere una applicazione con qualche meccanismo software (ad es. la lettura delle caratteristiche della macchina su cui il cliente installa la sua copia) occorre evitare che una semplice decompilazione + ricompilazione possa permettere ad un hacker neanche troppo esperto di bypassare la vostra protezione.

Non si tratta certo di problemi nati con .NET. Una quindicina di anni fa campavo sviluppando tool per programmatori con la mia azienda personale – la SoftWhale, dove “Whale” = “Balena” per chi non lo sapesse – e uno dei miei prodotti più gettonati era NOWAY, un programma che crittografava gli eseguibili MS-DOS proteggendoli quindi dalla decompilazione (un problema molto sentito da chi lavorava in Clipper) e permetteva di lanciarli solo sui computer per i quali la software house forniva al cliente dei codici di sblocco. NOWAY era scritto in puro Assembly 8086 e non è sopravvissuto al passaggio da MS-DOS a Windows.

In commercio esistono molti tool per .NET che servono a risolvere questi problemi, incluso obfuscator, compilatori “nativi” e chiavi hardware. Se volete proteggere la vostra IP (Intellectual Property) dovreste darci una occhiata approfondita.Per nostra fortuna, in Code Architects scriviamo soprattutto applicazioni Enterprise che non richiedono questo tipo di protezione, quindi non ho mai approfondito la questione. Immagino che questi tool facciano bene il loro lavoro, e li testerò se e quando avremo la necessità di farlo.

Se però (a) scrivete perlopiù applicazioni Windows Forms, (b) non vendete software pacchettizzato ed eseguite direttamente voi le installazioni presso il cliente, e (c) fate anche assistenza post-vendita, allora è possibile ottenere la protezione dalla decompilazione e dalle copie illegali con un meccanismo davvero molto semplice.

Cominciamo scrivendo una semplice applicazione Windows Forms. In questo esempio uso VB2005 ma ovviamente la tecnica si applica a qualsiasi linguaggio .NET.

Imports System.Reflection

Friend Module Module1

   <STAThread()> _

   Public Sub Main()

      ' in this demo we call the secret routine both directly and via reflection

      ' just to prove that either method works

       MySecretCode("Direct call")

       GetType(Module1).InvokeMember("MySecretCode", BindingFlags.InvokeMethod, _

          Nothing, Nothing, New Object() {"Reflection call"})

   End Sub

   Public Sub MySecretCode(ByVal title As String)

#If Not COPYPROTECT Then

      ' here goes all the code that you want to protect from decompilation

      MessageBox.Show("Running secret code!", title)

      ' ...

#End If

   End Sub

End Module

Poichè la variabile di compilazione COPYPROTECT non è definita, il codice nel metodo MySecretCode è incluso nell’eseguibile come se il blocco #IF non esistesse. In questo esempio proteggo un solo metodo, ma in una applicazione reale dovreste ripetere il procedimento con tutti i metodi che contengono del codice critico, magari dove implementate gli algoritmi più interessanti oppure dove controllate che l’utente abbia la licenza di eseguire il programma sul computer in questione. È importante che tutti i blocchi #IF... #ENDIF siano completamente contenuti in singoli metodi, ovvero che non capiti mai che uno di questi blocchi contenga le keyword Sub o Function (o le corrispettive End Sub o End Function). Per lo stesso motivo, potete utilizzare il meccanismo anche con le Property ma solo se utilizzate i blocchi #IF all’interno del blocco Get o Set. I blocchi #IF non devono assolutamente includere field, definizioni di eventi, o altro. 

Per completare la preparazione è opportuno definire una nuova configurazione per la soluzione. Dal menù Build selezionate il comando Configuration Manager, dalla combobox in alto a sinistra selezionate <New> e create una configurazione chiamata CopyProtected, che copia le impostazioni iniziali dalla configurazione Release.

Dopo esservi accertati che la nuova configurazione è quella attiva, create una costante condizionale di compilazione chiamata COPYPROTECT e impostata al valore True. In C# questa costante si crea dalla pagina Build delle proprietà di progetto, mentre in VB2005 dovete cliccare sul pulsante Advanced Compile Options che trovate nella pagina Compile:

Grazie a questa nuova configurazione, potete passare facilmente dalla versione normale (ossia Release) a quella copy-protected. Compilando l’applicazione in entrambe le configurazioni, avrete due eseguibili con lo stesso nome (ad es. Project1.exe) e contenenti gli stessi metadati (perchè le #IF sono sempre all’interno dei metodi e non includono campi, proprietà, o altro). L’esempio che segue presume che abbiate compilato una applicazione che si chiama Project1, che NON è firmata con uno strong name.

Preparate il setup, se necessario, utilizzando la versione Release, ma ricordatevi anche di memorizzare separatamente (ad es. su una chiavetta USB) l’eseguibile ottenuto in configurazione copy-protected e l’utility NGEN fornita con .NET Framework. Infine, recatevi presso il vostro cliente e seguite accuratamente la semplice procedura:

1) Lanciate il setup della applicazione, o più banalmente utilizzate XCOPY per copiare tutti i file sul disco rigido del cliente. In questo esempio supporremo che l’installazione sia avvenuta nella directory c:\myapp e che quindi il file eseguibile sia c:\myapp\Project1.exe.

2) Aprite una finestra di comandi, navigate nella directory che contiene l’esegubile e lanciate NGEN per creare una immagine in codice nativo della applicazione. Il comportamento di default di NGEN è OK, quindi non preoccupatevi troppo delle varie opzioni. (Lasciate aperta questa finestra, perchè vi servirà presto.)

3) Aprite una seconda finestra di comandi, navigate nella directory c:\windows\assembly\NativeImages_v2.0.50727_32\nomeassembly, dove nomeassembly è il nome dell’EXE ma senza l’estensione (Project1 in questo esempio). Noterete che in questa directory contiene una sottodirectory il cui nome è una stringa di caratteri esadecimali (nel mio esempio ho ottenuto d37032afe4f6f44588d52ca99d7bb1e5). Questa directory contiene un eseguibile dal nome nomeassembly.ni.exe (Project1.ni.exe nel nostro esempio), che contiene la versione compilata (senza IL e quindi non decompilabile) dell’eseguibile completo.

4) Dal prompt della seconda finestra dei comandi, con un comando COPY o MOVE spostate il file <nomeassembly>.ni.exe su qualche altra directory del disco rigido, ad esempio:
     MOVE d37032afe4f6f44588d52ca99d7bb1e5\Project1.ni.exe c:\
Questa operazione serve ad evitare che questo eseguibile sia cancellato dalla successiva invocazione di NGEN. Lasciate aperta anche questa seconda finestra dei comandi.

5) Sovrascrivete il file c:\myapp\Project1.exe con la versione copy-protected che avete sulla chiavetta USB.

6) Dalla prima finestra di comandi lanciate nuovamente NGEN, questa volta sulla versione copy-protected. Se questo programma venisse eseguito ora probabilmente andrebbe in errore o comunque non funzionerebbe bene, perchè alcune parti del codice non sono presenti, quindi NON lo mandate in esecuzione.

7) Dalla seconda finestra dei comandi, eseguite un comando DIR e noterete che la directory creata precedentemente (d37032afe4f6f44588d52ca99d7bb1e5, in questo esempio) è stata sostituita oppure è stata affiancata da un’altra directory dal nome random. (Nell’esempio che sto eseguendo mentre scrivo queste note è stata creata una directory di nome 9990426218ec334e9d3d62f41cb9a255.) Questa nuova directory contiene una nuova versione di Project1.ni.exe, che corrisponde alla versione in codice nativo dell'’eseguibile incompleto.

8) Sempre dalla seconda finestra dei comandi, copiate la copia precedente di Project1.ni.exe (salvata al punto #4) sulla nuova copia, ad esempio con questo comando:
     MOVE c:\project1.ni.exe 9990426218ec334e9d3d62f41cb9a255
rispondendo Yes alla domanda se intendiamo sovrascrivere il file Project1.ni.exe.

Fatto! Ora potete staccare la chiavetta USB e lasciare sul disco rigido del vostro cliente solo l'assembly "copy-protected" (in versione IL) e l'assembly completo (solo in versione compilata in modo nativo e quindi non decompilabile). Per quanto può sembrare incredibile, l'applicazione funziona correttamente e mostra le due message box Ma se provate a usare ILDASM o Reflector per sbirciare dentro il metodo MySecretCode (e qualsiasi altro metodo il cui interno è racchiuso con un #IF Not COPYPROTECT) troverete che il metodo è vuoto!

Ovviamente neanche Reflector riesce a decompilare alcunchè, visto che proprio manca il codice IL. Nè aiuta usare ILDASM sull’eseguibile Project1.ni.exe, perchè l’unica cosa che si ottiene è visualizzare un manifest senza codice IL:

Come può funzionare questa piccola magia? La spiegazione è semplice: quando lanciate un qualsiasi eseguibile .NET, per prima cosa il CLR va a controllare se vi è una “native image” che corrisponde esattamente a quella applicazione, e la corrispondenza viene cercata confrontando il nome della applicazione e la sua firma (la stringona esadecimale). Se esiste una immagine nativa, quella viene lanciata al posto dell’eseguibile. La condizione però perchè tutto il codice funzioni correttamente è che i metadati coincidano anch’essi, altrimenti troppe funzioni del CLR non funzionerebbero a dovere (il garbage collector, tanto per citarne il più importante). Nel nostro caso noi abbiamo creato due eseguibili con gli stessi metadati (ecco perchè è importante che i blocchi #IF non devono eliminare alcun metodo, campo, o proprietà), e siamo riusciti a mantenere sul disco rigido la versione IL “incompleta” mentre mandiamo in esecuzione la versione nativa “completa”.

Oltre a proteggere dalla decompilazione, molto simpaticamente questo meccanismo protegge anche dalle copie illegali. Infatti, se provate a spostare tutti i file (compreso l’eseguibile Project1.ni.exe) su un’altro computer, è praticamente certo che l'applicazione NON funzionerà correttamente. Da quel che ho potuto capire, questo accade perchè il nome della directory creata da NGEN – ovvero la “firma” di un particolare eseguibile – dipende anche da qualche informazione di sistema e quindi varia da macchina a macchina.

Per quanto interessante, questa tecnica ha alcune limitazioni abbastanza serie:

A) Se si intende proteggere una DLL peer Windows Forms l'assembly non deve essere segnato con uno strong name. Il motivo è che nel manifest degli assembly che referenziano una DLL con strong-name viene memorizzato anche l'hash dell'assembly in questione, e questo è un valore che cambia quando si compila la versione copy-protected. Quindi, visto che la DLL non può avere uno strong-name, neanche gli EXE che usano la DLL possono averlo, il che rappresenta una limitazione notevole. Questo limite non esiste per le applicazioni ASP.NET.

B) Se avviene un errore in una applicazione ASP.NET protetta oppure si modifica il Web config in qualsiasi modo, l'applicazione smette di funzionare. Il problema si risolve con un IISRESET.

C) Se avviene qualche modifica sostanziale all’hardware o al software di sistema – ad es. la sostituzione della CPU, l’aggiunta di memoria, l'upgrade del sistema operativo, ecc. – il .NET Framework non può più usare l’immagine nativa e lancerà l’eseguibile normale, che ovviamente non funzionerà bene perchè alcune porzioni di codice mancano. In quel caso occorre ripetere l’installazione e tutto il procedimento descritto sopra. È importante quindi mettere in guardia il vostro cliente dai rischi che corre facendo questi upgrade durante la notte, il fine settimana, o mentre siete in vacanza alle Bahamas.

Per mitigare il problema potete almeno fare in modo che l’applicazione mostri un chiaro messaggio di errore quando l’immagine nativa non è aggiornata e il CLR torna ad usare l’eseguibile “incompleto”. Per fare questo è sufficiente avere una istruzione MessageBox.Show in un blocco #IF COPYPROTECT (senza il Not), ad es:

Friend Module Module1
    Public Sub Main()     

#If COPYPROTECT Then

        MessageBox.Show("This app requires reinstallation. Please contact tech support.")

        Exit Sub

#End If

        ' Here the real application begins

        ' ...

    End Sub

End Module

Per quanto ne so, Microsoft non ha mai documentato quali modifiche al sistema disabilitano l’immagine nativa creata con NGEN, quindi non posso essere più preciso su questo punto. Se qualcuno conosce qualche articolo che spiega questi casi, lo menzioni nei commenti.

Per il resto, ho fatto un po’ di prove, sembra che tutto quanto fili liscio e che la tecnica non abbia altre controindicazioni. Se vi imbattete in qualche problema, fatemelo sapere.

Finalmente ho trovato il tempo per controllare una a una tutte le segnalazioni dei lettori su errori tipografici riscontrati nel mio ultimo libro su Visual Basic. Il risultato è un nuovo documento di errata corrige, che potete scaricare dalla home page del libro. I numeri di pagina si riferiscono alla versione inglese del libro, ma i numeri di pagina nella versione italiana sono spesso identici o comunque molto vicini.

Per la comodità di chi ha già downloadato questo documento, ho marcato con "New" tutte le aggiunte recenti. Da notare che quasi tutte le correzioni ai sorgenti non impattano sul funzionamento del codice, ad eccezione di un fix che serve a correggere un errore nella routine Evaluate del capitolo sulle regular expression.

Purtroppo non riesco a stare dietro ai vari commenti a questo blog, e ogni tanto me ne perdo qualcuno davvero interessante. In particolare, non avevo letto subito quello di Pasquale Esposito a un mio post di fine Aprile. In quel post parlavo di una mia DLL per VB6 e chiudevo chiedendo ai lettori VB6 quando si sarebbero decisi a passare a .NET. Pasquale ha risposto con un commento lungo e esauriente, di cui riporto qui i pezzi salienti:

Ci chiedi quand'è che ci decidiamo a migrare a VB.NET. Vedi, io sono rimasto profondamente deluso dal passaggio al byte code operato dalla Microsoft. Da circa dieci anni produco software shareware che distribuisco su Internet o nei CD allegati a riviste di informatica (ultima pubblicazione: Soluzione Bilancio 1.0 recensito a pag. 97 di PC Magazine di maggio 2006). Ho provato a tastare il terreno distribuendo qualche piccolo applicativo in .NET e mi sono subito reso conto che i tempi non sono affatto maturi per passare a questa tecnologia, almeno per chi utilizza la metodologia shareware come canale di distribuzione. Lo affermo per almeno due motivi:

1) Non è per niente facile chiedere ad un utente che non ha il Framework installato sulla propria macchina di scaricarlo da Internet solo per far funzionare la propria applicazione: per chi non ha una connessione ADSL sognificherebbe effettuare un download di qualche ora. Inoltre, anche chi ha installato il SP2 di WinXP, non è detto che abbia scelto di includere il Framework. Conclusione: molto probabilmente, l'utente in questione sceglierà di rinunciare all'applicativo in .NET e cercherà qualcos'altro di meno problematico. In poche parole, il "DLL Hell" di VB6 ha lasciato il posto al ".NET Framework Hell" di VB.NET.

2) Programmare in byte code significa produrre software estremamente vulnerabile, non solo dal punto di vista del cracking ma perfino da quello del reverse-engineering. Basta pochissima esperienza per entrare in possesso del codice sorgente altrui ed è necessario ricorrere a buoni obfuscator di terze parti per proteggere le proprie applicazioni. Questi strumenti non soltanto sono alquanto costosi ma molto spesso fanno uso di codice nativo (anziché di byte code), rendendo la piattaforma .NET non più autosufficiente. Conclusione: non ritengo che programmare in byte code sia conveniente per chi produce shareware. Al contrario, un applicativo in VB6 può essere crackato soltanto da esperti e in nessun caso è possibile ottenere i sorgenti. Il byte code, quindi, non è adatto a fini commerciali. Molti programmatori VB6 non lo hanno mai preso in considerazione, altrimenti sarebbero passati a Java già molto tempo fa.

.....

L'unico motivo che mi potrebbe far pensare alla migrazione a VB.NET è il timore che, dopo Windows Vista, Microsoft possa abbandonare strategicamente la tecnologia COM a 32 bit. Spero davvero che ciò non accada perché ciò significherebbe costringere la gente a buttare via tutto il software attualmente in commercio. Insomma, VB6 è senz'altro lo strumento che utilizzerò nei prossimi 4-5 anni dato che i runtime di base saranno ancora presenti in Windows Vista (lo stesso Microsoft Anti-Spyware è stato progettato in VB6), dopodiché potrò considerare l'ipotesi di effettuare la migrazione.

.....

La richiesta che vorrei rivolgerti è questa: VB6 non è morto. E non è neanche obsoleto. Molti programmatori si g uadagnano da vivere con VB6 e vorrebbero che tu ti occupassi ancora di questo strumento. Come hai reso il tuo MsgHookX nuovamente disponibile online, così dovresti fare con tutta la tua produzione che riguarda VB6. Anzi, dovresti creare ancora per l'ambiente VB6. Infine, se puoi, riferisci alla Microsoft che esiste ancora un esercito di programmatori VB6 che sarebbe pronto ad acquistare una nuova versione unmanaged del suo strumento di sviluppo. Dal punto di vista commerciale, sarebbe senz'altro una mossa vincente!

*) Le dimensioni del runtime: La stesso problema se lo ponevano i programmatori shareware 10 anni fa, quando confrontavano il runtime di VB6 con i piccoli eseguibili scritti in C. Ma allora c'è da chiedersi: perchè gli shareware-isti che lavorano in VB hanno avuto spesso più successo di quelli che lavorano in altri linguaggi come C ? La risposta, a mio avviso, è che scrivere un programma in VB richiedeva una frazione del tempo necessario a scriverlo in C quindi a parità di impegno è possibile creare programmi più potenti e ricchi di funzioni. (solo il Delphi può competere con VB quanto a produttività ) Forse non altrettanto veloci di quelli scritti in C, ma sufficientemente veloci per la maggior parte dei compiti.

Rapportiamo questa esperienza ad oggi: i 20M circa del framework sono circa 15 volte più grandi del runtime di VB6, pero' è anche vero che ADSL è almeno 15 volte più veloce del dialup, quindi la proporzione regge. Anzi, se i vostri clienti hanno la fibra ottica, neanche se ne accorgono. Insomma, chi tanti anni fa ha fatto la scelta di passare a VB infischiandosene delle dimensioni del runtime ha avuto ragione. Secondo me, lo stesso accade a chi oggi decide di passare a VB.NET

Certo, non tutti gli utenti hanno la ADSL, ma il ragionamento che farei io se fossi un autore shareware è: quanto mi interessano davvero questi utenti? i clienti migliori per il software e per i servizi sono le aziende e il power-user, e quelli l'ADSL ce l'hanno sempre. Se qualcuno non ha i 20€ al mese per pagare la connettività, difficilmente pagherebbe per i miei programmi. Gli unici che non rientrano in questo mio ragionamento sono le aziende e gli utenti che spenderebbero volentieri questi soldi, ma purtroppo non sono serviti da ADSL. Pero' oggettivamente si tratta di casi che diventeranno sempre più rari, e penso che in 2-3 anni saranno impossibili da trovare. (A parte il fatto che uno si puo' collegare a internet anche con una scheda UMTS...)

Allora, la domanda da porsi è: se sono un autore di software (shareware o non), vale la pena davvero continuare ad usare uno strumento che era eccezionale 10 anni fa ma adesso è decisamente superato? In questi anni io credo di avere dimostrato di saper fare davvero di tutto con il "vecchio Visual Basic", eppure oggi quando devo tornare a scrivere codice con VB6 mi sento un impedito. Non si tratta solo del linguaggio, ma anche dell'IDE e degli strumenti a corredo. Dopo pochi mesi con il VB.NET ero già molto più produttivo che in VB6 (che avevo usato per 10 anni). Oggi che conosco bene il .NET Framework credo di essere, mediamente, almeno tre volte più veloce. Ovvero scrivo un programma in un terzo del tempo che ci mettevo prima. Io vendo programmi principalmente ad aziende, ma anche se facessi shareware mi porre la stessa domanda: vale la pena rinunciare a questa enorme produttività per raggiungere qualche utente in più, che probabilmente non comprerebbe comunque il mio software?

*) Anche se il .NET Framework è ben pesante, non è strettamente necessario distribuirlo tutto con le proprie applicazioni. In teoria una applicazione WinForm ha bisogno di circa un terzo dell'intero framework. Anche se non mi sono mai interessato più di tanto alla questione, ho letto che ci sono dei programmi che sono in grado di comprire un eseguibile .NET e tutte e sole le librerie che utilizza , senza cioè richiedere una installazione completa del framework. Se le dimensioni del runtime fossero davvero un problema, proverei a fare qualche ricerca più approfondita su questi prodotti.

*) come lo stesso Pasquale fa notare, lo shareware si puo' diffondere anche con mezzi che non siano Internet, ad es. sui CD allegati alle riviste. Pero' è un dato di fatto che ci sono sempre meno riviste che allegano i CD, proprio perchè la maggior parte degli utenti ha una linea veloce e preferisce scaricare dalla Rete per essere sicuri di avere la versione più recente. Ad esempio, Microsoft Press, Mondadori e altri publisher importanti non allegano più i CD ai propri libri (a meno che il contenuto non superi i 30-40M) e loro prendono queste decisioni solo dopo analisi di mercato fatte per bene.

*) se fossi un programmatore VB6, a rendere ancora più semplice e più netta la mia decisione di passare a .NET c'è la considerazione che tutto quello che scrivo oggi con VB6 dovrà forzatamente essere buttato via tra qualche anno, vuoi perchè Microsoft non supporterà più VB, vuoi perchè i programmi e i controlli ActiveX potrebbero non funzionare bene con le prossime versioni di Windows. E' giusto fare pressione su Microsoft per evitare che cio' avvenga, ma le probabilità di fare rimangiare le loro decisioni sono prossime allo zero. Quindi è un piccolo "suicidio professionale" puntare tutto su questa speranza e nel frattempo fare finta che il mondo sia quello di dieci anni fa. Se consigliassi a qualcuno di continuare a scrivere codice VB6 sarei un vero incosciente.

*) Il discorso sul byte code: E' innegabile che un programma che possa essere decompilato facilmente pone dei seri problemi. Purtroppo .NET non offre una netta risposta a questo problema, ma solo mezze soluzioni (tipo installare sul server come servizio o sito asp.net). Quando Microsoft lanciò le prime beta di .NET cinque anni fa, questo aspetto mi sembrava davvero fondamentale, in grado addirittura di rallentare la diffusione del nuovo linguaggio.

Le cose sono andate diversamente, per fortuna. C'è da tenere presente che il problema del reverse-engineering è molto sentito da tutti i programmatori, non solo quelli che vendono shareware. Se uno mette sul mercato uno shareware e qualcuno ne fa il reverse engineering, è molto facile dimostrare che il nuovo programma è un clone. Basta decompilarli entrambi e mostrare a tutto il mondo il risultato, sottolineando che il proprio programma è stato messo sul mercato prima del clone. Certo non è efficace quanto una azione legale (che pure è possibile, ma costosa) ma nel mondo di Internet è sufficiente per perdere la reputazione. Certo, uno puo' fare il reverse engineering e poi modificare il codice, ma è facile mettere delle "trappole" in giro per il sorgente, ossia delle istruzioni che non fanno nulla e che chi ha clonato il programma non saprebbe giustificare. Per togliere queste trappole uno si deve studiare meglio tutto il sorgente, ma allora il lavoro del copiatore si complica.

A parte queste considerazioni, c'è da sottolineare il fatto che questo problema è sempre esistito nel mondo dello sviluppo software. Molti linguaggi che in passato hanno avuto successo erano dei byte-code decompilabili: ad esempio dBASE, il Clipper (spacciato come compilatore), Java, e lo stesso Visual Basic fino alla versione 4.0. E anche se il linguaggio era compilato, resta il fatto che i tracciati dei record e le tabelle dei database - ovvero un aspetto fondamentale delle applicazioni gestionali - sono sempre stati visibili e interpretabili. Se vuoi capire come funziona un gestionale, la prima cosa da fare è vedere come sono strutturate le sue tabelle del DB.

Insomma, non sto dicendo che il problema non esiste: sto dicendo che è meno serio di quello che molti programmatori credono.

Termino il post rispondendo direttamente a Pasquale: hai ragione a dire che VB6 non è morto. Ci sono moltissimi programmatori che ancora lo usano e il mio libro su VB6 continua a vendere abbastanza bene, addirittura meglio di alcuni libri su VB.NET (non dei miei libri su VB.NET, per fortuna! )

Pero' hai (molto) torto a dire che NON è obsoleto. Non si tratta di "rinnegare" il passato e soprattutto non dobbiamo parlare di VB come di un cagnolino a cui ci siamo affezionati, che non si vuole rottamare per ragioni sentimentali (ho letto anche interventi di questo tenore sui vari forum....). Quando è nato era eccezionale e per anni io ho campato (e bene!) con questo prodotto, ma se lo confronti con VB.NET (e con l'IDE di Visual Studio 2005) ti accorgi che il Visual Basic 6 è davvero morto e sepolto.

Ecco perchè non ho firmato alcuna petizione pro-VB6 e perchè sto facendo di tutto per convincere gli sviluppatori VB6 a passare il prima possibile a .NET: quando cominci a lavorare con la programmazione ad oggetti "vera", con gli attributi e reflection, i controlli di Windows Forms, le applicazioni ASP.NET e tutto il resto, il Visual Basic 6 ti sembra tanto ma tanto lontano.

NOTA: anche se non sviluppo più sotto VB6, forse cercando sul mio disco rigido troverei qualche cosa interessante che non ho ancora pubblicato. In tal caso sarà un piacere metterla a disposizione di tutti su questo sito. L'ho fatto per anni e posso continuare a farlo anche ora...

In Visual Basic 6 esiste una comodissima proprietà dell'oggetto App che permette di determinare se vi sono altre istanze in esecuzione della stessa applicazione. Manco a dirlo, questa proprietà non è mai stata migrata in VB.NET anche se, per fortuna, una applicazione scritta in VB 2005 può almeno usare l'evento StartupNextInstance:

' to display this code, open the Application page of the My Project designer and click the Application Events button
Namespace My
   Partial Friend Class MyApplication
      Private Sub MyApplication_StartupNextInstance(ByVal sender As Object, ByVal e As Microsoft.VisualBasic.ApplicationServices.StartupNextInstanceEventArgs) Handles Me.StartupNextInstance
         ' another instance of this application has been launched
      End Sub
   End Class
End Namespace

In pochi giorni mi sono arrivate due mail da altrettanti lettori, che chiedono come sia possibile - in una finestra Windows Forms che sfrutta l'evento Validating dei controlli per validare l'input - saltare la validazione se l'utente chiude il form. Se non si salta la validazione, infatti, l'effetto è che l'utente potrebbe non riuscire a chiudere il form. La risposta è molto semplice, ma evidentemente non è proprio ovvia, quindi la ripeto qui a beneficio di tutti.

Se l'utente chiude un form cliccando sul pulsante "X" o scegliendo "Close" dal menu di sistema, scatta prima l'evento Validating del controllo che ha il focus poi, anche se il primo evento ha decretato che la validazione è fallita, scatta l'evento FormClosing. La cosa interessante è che, se l'evento Validating ha impostato e.Cancel = True, nell'evento FormClosing è possibile resettare questo valore a False. In definitiva, quindi, per evitare che il codice nell'evento Validating impedisca all'utente di chiedere il form sono sufficienti queste istruzioni:

Private Sub Form1_FormClosing(ByVal sender As Object, ByVal e As FormClosingEventArgs) Handles Me.FormClosing
   If e.CloseReason = CloseReason.UserClosing OrElse e.CloseReason = CloseReason.WindowsShutDown Then
      e.Cancel = False
   End If
End Sub

Ieri mi scrive un mio lettore, Claudio Fontana, con una richiesta apparentemente semplice: come fare per evitare sfarfallii strani quando si devono aggiornare la maggior parte dei controlli sul form? Il problema si fa sentire soprattutto quando occorre aggiungere migliaia di elementi a listbox e treeview.

In VB6 questo problema si risolveva molto semplicemente impostando la proprietà Visible (o Enabled) a False durante l'aggiornamento, e re-impostandola a True alla fine delle operazioni: la cosa interessante è che, a meno di non inserire una istruzione Refresh esplicita, il controllo non veniva effettivamente reso invisibile o "grayed", ma il suo nuovo contenuto appariva di botto, senza alcun effetto di flickering. Non solo: se il controllo veniva reso invisibile l'aggiornamento veniva anche eseguito molto più velocemente, tipicamente nella metà del tempo solitamente necessario. Sfortunatamente, in .NET il trucco di rendere i controlli temporaneamente invisibili non funziona più, nel senso che il refresh avviene effettivamente e quindi il controllo scompare effettivamente per tutta la durata dell'aggiornamento. Occorre pensare a qualcos'altro.

Alcuni controlli Windows Forms espongono i metodi BeginUpdate e EndUpdate, che di fatto ottengono non solo di "congelare" un controllo durante le operazioni di aggiornamento ma anche di sveltire notevolmente le operazioni stesse, che diventano anche 2.5 volte più veloci. Però solo quattro controlli espongono questa proprietà: ListBox, ComboBox, TreeView e ListView. Se il vostro form contiene molti controlli di altro tipo è necessario pensare a qualcos'altro, e questo è il problema che mi ha sottoposto Claudio, dopo aver googlato a destra e a manca sulla Rete alla ricerca di una soluzione, senza alcun esito.

Poichè il problema era intrigante, ho deciso di dedicarci qualche minuto, e sono arrivato ad una soluzione abbastanza interessante e (se Claudio ha googlato bene) anche inedita. L'idea è davvero molto semplice: (1) si "fotografa" l'aspetto corrente del form, copiandolo pixel per pixel in una bitmap, (2) si crea un controllo PictureBox grande quanto il form e si carica la bitmap nella PictureBox, (3) si aggiunge la PictureBox alla collection Controls e la si porta in primo piano, in modo da coprire tutti gli altri controlli, (4) mentre l'utente vede l'immagine congelata del form, si aggiornano tutti i controlli, usando i metodi BeginUpdate/EndUpdate se possibile per velocizzare le operazioni, (5) quando l'update è completato, si elimina la PictureBox in modo che l'utente torni a vedere il vero contenuto del form.

Tutto questo algoritmo è in realtà molto semplice, e si riduce a una decina di righe. Però ho pensato di creare una classe ad-hoc, in modo che il codice sia facilmente riutilizzabile, rilasci correttamente le risorse, e si protegga da utilizzi errati:

Public Class FormFreezer
   Implements IDisposable

   ' The form being frozen
   Dim Form As Form
   ' the auxiliary PictureBox that will cover the form
   Dim PictureBox As PictureBox
   ' the number of times the Freeze method has been called
   Dim FreezeCount As Integer = 0

   ' create an instance associated with a given form
   ' and optionally freeze the form right away
   Public Sub New(ByVal form As Form, Optional ByVal freezeIt As Boolean = False)
      Me.Form = form
      If freezeIt Then Me.Freeze()
   End Sub

   ' freeze the form 
   Public Sub Freeze()
      ' Remember we have frozen the form once more
      FreezeCount += 1
      ' Do nothing if it was already frozen
      If FreezeCount > 1 Then Exit Sub

      ' Create a PictureBox that resizes with its contents
      PictureBox = New PictureBox()
      PictureBox.SizeMode = PictureBoxSizeMode.AutoSize
      ' create a bitmap as large as the form's client area and with same color depth
      Dim frmGraphics As Graphics = Form.CreateGraphics()
      Dim rect As Rectangle = Form.ClientRectangle
      PictureBox.Image = New Bitmap(rect.Width, rect.Height, frmGraphics)
      frmGraphics.Dispose()

      ' copy the screen contents, from the form's client area to the hidden bitmap
      Dim picGraphics As Graphics = Graphics.FromImage(PictureBox.Image)
      picGraphics.CopyFromScreen(Form.PointToScreen(New Point(rect.Left, rect.Top)), New Point(0, 0), New Size(rect.Width, rect.Height))
      picGraphics.Dispose()

      ' Display the bitmap in the picture box, and show the picture box in front of all other controls
      Form.Controls.Add(PictureBox)
      PictureBox.BringToFront()
   End Sub

   ' unfreeze the form
   ' Note: calls to Freeze and Unfreeze must be balanced, unless force=true 
   Public Sub Unfreeze(Optional ByVal force As Boolean = False)
      ' exit if nothing to unfreeze
      If FreezeCount = 0 Then Exit Sub
      ' remember we've unfrozen the form, but exit if it is still frozen
      FreezeCount -= 1
      ' force the unfreeze if so required
      If force Then FreezeCount = 0
      If FreezeCount > 0 Then Exit Sub

      ' remove the picture box control and clean up
      Form.Controls.Remove(PictureBox)
      PictureBox.Dispose()
      PictureBox = Nothing
   End Sub

   ' return true if the form is currently frozen
   Public ReadOnly Property IsFrozen() As Boolean
      Get
         Return FreezeCount > 0
      End Get
   End Property

   ' ensure that resources are cleaned up correctly
   Public Overridable Sub Dispose() Implements IDisposable.Dispose
      Me.Unfreeze(True)
   End Sub
End Class

Questo è invece la versione C#, tradotta da Claudio:

Usare la classe FormFreezer è semplicissimo. Ecco un esempio di codice (che deve trovarsi all'interno di una classe Form, in modo che Me punti al form corrente):

   Dim ff As New FormFreezer(Me, True)
   ' update controls here
   ' ...
   ff.Unfreeze()

MsgHookX è una DLL ActiveX che permette ai programmatori VB6 di eseguire un subclassing intra-applicazione sicuro ed efficiente, ossia di intercettare qualsiasi messaggio che Windows invia a un controllo o finestra della applicazione corrente. Scrissi questa DLL diversi anni fa, ai tempi del VB5, e l'ho utilizzata in alcuni libri e articoli usciti nel frattempo. Questa DLL era disponibile sul vecchio sito VB2TheMax, ma non è sopravvissuta quando il sito è diventato .NET-2-The-Max e decidemmo di scartare tutti i contenuti relativi al vecchio VB6.

Beh, se devo giudicare dalle tante mail che continuo a ricevere dai lettori, si direbbe che gli sviluppatori VB6 continuano a voler subclassare i loro controlli e le loro finestre. Per questa ragione ho deciso di rendere MsgHookX nuovamente disponibile, sul sito americano a questo URL. Ecco un breve sommario di quello che la DLL è in grado di fare:

• subclassing sicuro: può essere usata nella IDE e in break mode, senza rischiare alcun crash di sistema.
• fornisce gli eventi BeforeMessage e AfterMessage, per una programmazione semplice di tipo event-driven
• è anche in grado di notificare l'arrivo dei messaggi attraverso l'interfaccia secondaria IMsgHookEvents, per fornire prestazioni migliore e un debugging più facile (in alcuni casi gli eventi sono inibiti nella IDE di VB6)
• alta flessibilità: potete decidere di chiamare la window procedure originale dall'evento/metodo BeforeMessage e opzionalmente di annullare l'elaborazione di default del messaggio. Potete anche visualizzare e modificare il valore che il messaggio sta per restituire al sistema operativo.
• La type library della DLL include la definizione di oltre 300 costante simboliche, che definiscono i messaggi Windows più comuni, in modo da non dover ricorrere all'API Viewer per includere le definizioni nella proprie applicazioni.

Ora la mia domanda è: ma quando, quando, quando vi deciderete a passare a .NET ?

Ieri ho dovuto risolvere un piccolo problema: durante la migrazione di una applicazione VB6 era necessario scartare un metodo, in modo cioè che fosse "invisibile" a VB.NET. Questo era necessario perchè il metodo in questione svolgeva le stesse funzioni di un metodo nativo di .NET. Ovviamente, è sempre possibile cancellare il metodo dopo la migrazione, ma se i metodi sono tanti oppure se occorre lanciare più volte il wizard sullo stesso programma VB6 dopo rifiniture successive, allora la cosa diventa scocciante.

Apparentemente, non si puo' dire al migration wizard di ignorare dei pezzi di codice, però la soluzione è comunque molto semplice. Basta racchiudere il pezzo di codice in questione (interi metodi o anche singole istruzioni) in un blocco #IF WIN32. La costante di compilazione WIN32, di cui probabilmente pochi programmatori VB6 si ricordano, fu introdotta ai tempi di Visual Basic 4, l'unica versione di questo linguaggio ad essere disponibile nella versione a 16 e 32 bit, e questa costante (insieme a WIN16) permetteva appunto di definire blocchi di codice che venivano compilati solo in una delle due versioni, dando allo stesso tempo la possibilità di manutenere un unico sorgente per entrambe. In definitiva quindi, il seguente pezzo di codice VB6:

#If WIN32 Then
   Private Sub Do Something(ByVal n As Integer)   
      ' ...
   End Sub
#End If

viene correttamente migrato dal wizard nel seguente codice VB.NET

#If WIN32 Then
   Private Sub DoSomething(ByVal n As Short)
      ' ...
   End Sub
#End If

Molti, se non la maggior parte, degli esempi di controlli Windows Forms che si trovano in giro per la rete contengono chiamate a codice unmanaged nelle DLL di Windows, in particolare uno o più metodi SendMessage per ovviare alle (pochissime) mancanze controlli del .NET Framework. Il problema è che un controllo del genere crea dei problemi quando l'applicazione viene eseguita in modalità ClickOnce, poichè richiede di modificare la CAS associata alla particolare applicazione.

Anche se questo problema non ha soluzione in generale, quando si intende inviare un messaggio al controllo che si sta subclassando è possibile fare a meno di una chiamata esplicita a SendMessage e usare invece il metodo protetto DefWndProc che viene ereditato dalla classe Control. Supponiamo ad esempioi di voler scrivere una ComboBox "enhanced", che espone la proprietà TopIndex, che imposta o restituisce l'indice del primo elemento visibile nella porzione di lista del controllo. Queste due operazioni si possono implementare inviando rispettivamente i messaggi CB_SETTOPINDEX e CB_GETTOPINDEX al controllo. Ecco come fare, usando il metodo DefWndProc invece di SendMessage:

Public Class ComboBoxEx
   Inherits System.Windows.Forms.ComboBox

   Public Property TopIndex() As Integer
      Get
         Const CB_GETTOPINDEX As Int32 = &H15B
         Dim m As New Message()
         m.HWnd = Me.Handle
         m.Msg = CB_GETTOPINDEX
         Me.DefWndProc(m)
         Return m.Result.ToInt32()
      End Get
      Set(ByVal value As Integer)
         Const CB_SETTOPINDEX As Int32 = &H15C
         Dim m As New Message()
         m.HWnd = Me.Handle
         m.Msg = CB_SETTOPINDEX
         m.WParam = New IntPtr(value)
         Me.DefWndProc(m)
      End Set
   End Property

End Class

Nel mio post di ieri dicevo che probabilmente avrei partecipato alla conferenza del 23 marzo a Milano con Jay Roxe e Tyler Whitney, rispettivamente Product Manager di Visual Studio e Technical Lead di Visual Basic.

Mi devo correggere: sicuramente parteciperò alla conferenza in questione, visto che parlerò anche al keynote iniziale, in compagnia di Francesco Albano di Microsoft Italia. Ecco l'abstract della nostra sessione:

MIGRAZIONE DELLE APPLICAZIONI VB6 IN VB.NET
Anche se il numero delle software house che utilizzano Visual Studio cresce di giorno in giorno, il passaggio al mondo .NET è in qualche modo ritardato dalla presenza di numerose applicazioni “legacy” scritte in Visual Basic 6. In questa sessione si discuterà del processo di adozione di VB.NET e di come utilizzare le nuove feature di Visual Basic 2005 per facilitare la conversione di applicazioni VB6.

Tempo permettendo, durante la sessione farò anche vedere in anteprima uno strumento a cui sto lavorando da un mesetto circa, che non mancherà di interessare chi ha intenzione di migrare in maniera "indolore" le applicazioni VB6 esistenti e non vuole impazzire con il wizard incluso in Visual Studio. Maggiori informazioni a breve su questo blog....

Il 23 marzo a Milano c'è una conferenza da non perdere, non solo per l'argomento in sè - le novità di VB2005 e VSTO - quanto per la presenza del product manager di Visual Studio Jay Roxe e del Visual Basic Technical Lead Tyler Whitney. La conferenza è in inglese, ma Microsoft fornisce gentilmente cuffiette e traduzione simultanea. Maggiori informazioni su http://www.microsoft.com/italy/msdn/eventi/vbasic.mspx

Se ce la faccio, farò un salto pure io, quindi è probabile che ci vedremo là.  Per me che vivo a Bari, "un salto" significa svegliarmi alle 4 e prendere un paio di aerei....

Sto riorganizzando la mia collection di MP3 e mi sono trovato nella necessità di rinominare un numero davvero enorme di file. Ci sono molte utility sul mercato che permettono di farlo (e che sono anche in grado di usare i tag MP3 per rinominare i file), ma ho pensato che tanto valeva scriverne una io. Tanto, grazie alle regex il compito non sarebbe stato difficile. E infatti in qualche minuto ho tirato fuori il seguente codice. Come vedete, la maggior parte delle istruzioni servono a estrarre e validare gli argomenti dalla riga di comando:

Imports System.Text.RegularExpressions
Imports System.IO

Module Renx

   Function Main(ByVal args() As String) As Integer
      Console.WriteLine("RENX (C) Francesco Balena / Code Architects Srl")

      Dim recurse As Boolean = False
      Dim renameMode As Boolean = False
      Dim oldNamePattern As String = Nothing
      Dim newNamePattern As String = Nothing

      ' analyze each argument
      For Each arg As String In args
         Select Case arg.ToLower()
            Case "/s", "-s"
               recurse = True
            Case "/r", "-r"
               renameMode = True
            Case "/h", "-h"
               Return ShowHelp(0)
            Case Else
               If oldNamePattern Is Nothing Then
                  oldNamePattern = "^" & arg & "$"
               ElseIf newNamePattern Is Nothing Then
                  newNamePattern = arg
               Else
                  Return ShowHelp(1)
               End If
         End Select
      Next

      ' check that we have both mandatory arguments
      If oldNamePattern Is Nothing OrElse newNamePattern Is Nothing Then
         Return ShowHelp(1)
      End If
      ' create the regex and check that pattern syntax is ok
      Dim reSearch As Regex
      Try
         reSearch = New Regex(oldNamePattern, RegexOptions.IgnoreCase)
         ' test the replace pattern as well
         Dim tmp As String = reSearch.Replace("a dummy string", newNamePattern)
      Catch ex As Exception
         Console.WriteLine("SYNTAX ERROR: {0}", ex.Message)
         Return 3
      End Try
      Console.WriteLine()

      ' iterate over all files in current directory (and its subdirectories, if recurse mode)
      Dim searchOpt As SearchOption = SearchOption.TopDirectoryOnly
      If recurse Then searchOpt = SearchOption.AllDirectories

      Dim parsedFilesCount As Integer = 0
      Dim renamedFilesCount As Integer = 0
      Dim errorsCount As Integer = 0
      For Each oldFile As String In Directory.GetFiles(Directory.GetCurrentDirectory(), "*.*", searchOpt)
         parsedFilesCount += 1
         ' the regex applies to name only
         Dim oldName As String = Path.GetFileName(oldFile)
         Dim ma As Match = reSearch.Match(oldName)
         If ma.Success Then
            ' this is the new name
            Dim newName As String = ma.Result(newNamePattern)
            Console.WriteLine(oldFile)
            Console.Write(" => {0}", newName)
            renamedFilesCount += 1
            ' proceed with rename only if not in simulation mode
            If renameMode Then
               Try
                  Dim dirName As String = Path.GetDirectoryName(oldFile)
                  Dim newFile As String = Path.Combine(dirName, newName)
                  File.Move(oldFile, newFile)
               Catch ex As Exception
                  Console.Write(" -- ERROR: {0}", ex.Message)
                  errorsCount += 1
               End Try
            End If
            Console.WriteLine()
         End If
      Next

      ' Display a report
      If renameMode Then
         Console.WriteLine("Summary: {0} parsed files, {1} renamed files, {2} errors", parsedFilesCount, renamedFilesCount, errorsCount)
      Else
         Console.WriteLine("Summary: {0} parsed files, {1} files affected", parsedFilesCount, renamedFilesCount)
         Console.WriteLine()
         Console.WriteLine("NOTE: Running in simulation mode. Specify the /R option to actually rename files.")
      End If
      ' Return an error code
      If errorsCount = 0 Then
         Return 0
      Else
         Return 2
      End If
   End Function

   Function ShowHelp(ByVal exitCode As Integer) As Integer
      Console.WriteLine()
      Console.WriteLine("Syntax: RENX <oldnamepattern> <newnamepattern> [/R] [/S] [/H]")
      Console.WriteLine(" oldnamepattern : regex that selects the files to be renamed")
      Console.WriteLine(" newnamepattern : regex that specifies how files must be renamed")
      Console.WriteLine(" /R : rename files")
      Console.WriteLine(" /S : iterate over subdirectories")
      Console.WriteLine(" /H : display this help")
      Console.WriteLine("NOTE: By default the program runs in simulation mode, and just displays how files would be renamed.")
      Console.WriteLine(" You must specify the /R option to actually rename the files.")
      Return exitCode
   End Function

End Module

Al minimo, la utility RENX richiede due argomenti: una regex che individua quali file nella directory corrente (e nelle sue subdirectory, se si specifica l'opzione /S) devono essere rinominati, e una regex che specifica come rinominare i file che soddisfano la prima regex. La potenza di RENX sta nel fatto che la regex che individua i file può (anzi, deve) specificare uno o più gruppi di caratteri, che vengono poi riutilizzati nella seconda regex. Supponiamo ad esempio che abbia una directory con i seguenti file

        01 Speak to Me.mp3
        02 On the Run.mp3
        03 Time.mp3
        04 The Great Gig in the Sky.vbr
        05 Money.mp3
        06 Us and Them.mp3
        07 Any Colour You Like.vbr
        08 Brain Damage.mp3
        09 Eclipse.vb3

e li voglia rinominare in questo modo:

        01 - Speak to Me - The Dark Side of the Moon.mp3
        02 - On the Run - The Dark Side of the Moon.mp3
        03 - Time - The Dark Side of the Moon.mp3
        04 - The Great Gig in the Sky - The Dark Side of the Moon.vbr
        05 - Money - The Dark Side of the Moon.mp3
        06 - Us and Them - The Dark Side of the Moon.mp3
        07 - Any Colour You Like - The Dark Side of the Moon.vbr
        08 - Brain Damage - The Dark Side of the Moon.mp3
        09 - Eclipse - The Dark Side of the Moon.vbr

Ecco allora come invocare RENX per effettuare la trasformazione:

        RENX "(\d\d) (.+?)(\..+)"    "${1} - ${2} - The Dark Side of the Moon${3}"

Notate che la prima regex crea tre gruppi racchiudendo dei caratteri tra parentesi: (\d\d) fa il match con due cifre, mentre (.+?) fa il match con il nome del file, e infine (\..+) fa il match con l'estensione del file, punto incluso. Il secondo argomento puo' riordinare a piacere queste tre quantità, usando la sintassi ${N}, dove N è il numero d'ordine del gruppo individuato dalla prima regex, ed è quindi in grado di inserire un trattino dopo il numero del brano e il nome dell'album dopo il titolo del brano.

Data la pericolosità del comando di rename, per default il comando RENX *non* effettua il rename e si limita a mostrare come i file sarebbero rinominati. Per effettuare effettivamente il rename occorre specificare l'opzione /R:

        RENX "(\d\d) (.+?)(\..+)"    "${1} - ${2} - The Dark Side of the Moon${3}" /R

Questo è tutto. Avete il sorgente e potete estendere l'utility come preferite (magari per trasformarla in un programma Windows Forms), e potete anche effettuare il download della versione in binario da questo link: Renx.zip (5.51 KB)

Qualche minuto fa ho caricato tutti gli esempi a corredo di Programming Microsoft Visual Basic 2005: The Language sulla home page del libro. E' uno zippone di 7.5M, che contiene migliaia di righe di codice riutilizzabile, accuratamente scritte, testate e ottimizzate a manina. Tra le tante cose che potete trovare:

• una classe VB che lavora con le frazioni
• un form base per semplificare il data entry
• una classe per il caching dei file di testo
• alcuni custom iterator per scrivere dei For Each migliori
• dozzine di esempi con i generics
• due valutatori di espressioni, il primo basato sui regex, il secondo implementato tramite compilazione on-the-fly
• una utlity per mostrare le statistiche di un progetto VB (è una demo per le regex)
• RegexTester, una utility stand-alone per aiutarvi a costruire, testare, e compilare le regular expression
• un esempio di custom provider per My.Settings
• un esempio di come intercettare qualsiasi evento da qualsiasi controllo su un form
• benchmark basati su attributi custom
• una completa infrastruttura per scrivere applicazioni Windows Forms estendibili via plug-in
• attributi e DLL per scrivere applicazioni N-tier data-centriche
• numerose macro per Visual Studio
• visualizer per mostrare il contenuto di file, regex, e immagini durante il debug
• .... e molto altro.

Sulla stessa pagina ho caricato un document di errata per gli errori trovati dopo che il libro è andato in stampa, e alcuni capitoli di esempio. Per accedere alla pagina occorre registrarsi.

Divertitevi con il codice ( ... e comprate il libro se lo trovate interessante! )

Più lavoro con i generics più mi piacciano e più modi scopro per semplificare il mio codice mediante il loro utilizzo. In particolare, mi piace la possibilità di scrivere codice type-safe, più conciso ed efficiente ma soprattutto più leggibile perchè non contiene dozzine di CType e DirectCast. Oggi ho raccolto in questo modulo le funzioni generiche che uso più spesso nei miei programmi. Sono molto brevi e semplici, ma mi hanno fatto risparmiare un bel po' di tempo e codice.

Module GenericFunctions

   ' Swap two variables
   Public Sub Swap(Of T)(ByRef var1 As T, ByRef var2 As T)
      Dim tmp As T = var1
      var1 = var2
      var2 = tmp
   End Sub

   ' Type-safe version of the IIF function
   ' returns valueOnTrue if expression is True, else returns valueOnFalse
   Public Function IIf(Of T)(ByVal expression As Boolean, ByVal valueOnTrue As T, ByVal valueOnFalse As T) As T
      If expression Then
         Return valueOnTrue
      Else
         Return valueOnFalse
      End If
   End Function

   ' Type-safe version of the Choose function
   ' returns the N-th element of a list of values, or the default value for T if index
   ' is less than 0 or higher than the number of values
   Public Function Choose(Of T)(ByVal index As Integer, ByVal values() As T) As T
      If index >= 0 AndAlso index < values.Length Then
         Return values(index)
      Else
         Return Nothing
      End If
   End Function

   ' Return the min value of a list
   Public Function Min(Of T As IComparable)(ByVal firstValue As T, ByVal ParamArray values() As T) As T
      Dim result As T = firstValue
      For Each value As T In values
         If result.CompareTo(value) > 0 Then result = value
      Next
      Return result
   End Function

   ' Return the max value of a list
   Public Function Max(Of T As IComparable)(ByVal firstValue As T, ByVal ParamArray values() As T) As T
      Dim result As T = firstValue
      For Each value As T In values
         If result.CompareTo(value) < 0 Then result = value
      Next
      Return result
   End Function

   ' Return True if a value is in specific range
   Public Function InRange(Of T As IComparable)(ByVal testValue As T, ByVal minValue As T, ByVal maxValue As T) As Boolean
      Return testValue.CompareTo(minValue) >= 0 AndAlso testValue.CompareTo(maxValue) <= 0
   End Function

   ' Retrieve a dictionary element of a given type, or the provided default value if the element isn't found
   ' (two overloads)
   Public Function GetDictionaryValue(Of TKey, TValue)(ByVal dict As Hashtable, ByVal key As TKey, ByVal defaultValue As TValue) As TValue
      If dict.ContainsKey(key) Then
         Return CType(dict(key), TValue)
      Else
         Return defaultValue
      End If
   End Function

   Public Function GetDictionaryValue(Of TKey, TValue)(ByVal dict As Dictionary(Of TKey, TValue), ByVal key As TKey, ByVal defaultValue As TValue) As TValue
      ' If the key is in the dictionary, the following statement stores the corresponding value
      ' in defaultValue, else it leave defaultValue unchanged
      dict.TryGetValue(key, defaultValue)
      Return defaultValue
   End Function

End Module

In VB6 - e più in generale, nel mondo COM - un oggetto si distrugge semplicemente impostandolo a Nothing (ovviamente, nell'ipotesi in cui non vi siano altre variabili che puntano a quella particolare istanza). Il runtime di VB invoca il metodo Class_Terminate, se esiste un handler per tale evento, poi dealloca tutte le risorse assegnate all'oggetto, inclusa la mamoria. Questo processo è ricorsivo, quindi se l'oggetto possiede altri oggetti COM (ad es. una connessione ADO), anche quegli oggetti sono distrutti.

Sappiamo bene, invece, che in .NET impostare una variabile oggetto a Nothing non fa scattare alcun evento. Se l'oggetto implementa il metodo Finalize, tale metodo sarà chiamato dal garbage collector di .NET solo qualche tempo dopo. L'intervallo di tempo tra l'impostazione a Nothing e l'esecuzione del codice di cleanup contentuo nel metodo Finalize dipende da tanti fattori, e potrebbe arrivare anche a minuti o ore, se il programma non alloca molti altri oggetti e quindi non stressa il garbage collector.

Questa differenza nel comportamento tra VB6 e VB.NET diventa spesso un problema davvero serio nella migrazione delle applicazioni. Se ad esempio il codice nell'evento Class_Terminate chiude una connessione al database, oppure un file o una porta seriale, oppure cancella delle informazioni confidenziali, o chiude un form, allora il ritardo tra la distruzione "logica" dell'oggetto e la sua distruzione "fisica" può compromettere il funzionamento della applicazione stesso, dopo la sua migrazione verso il mondo .NET.

Purtroppo non è possibile ottenere "in automatico" che VB.NET si comporti esattamente come VB6 in questo caso, pero' possiamo fare qualcosa che riduce il problema. Questo è possibile, ancora una volta, grazie ai generics. Basta inserire il metodo seguente in un modulo, in modo da renderlo visibile a tutta l'applicazione:

Public Sub SetNothing(Of T)(ByRef obj As T)
   ' Dispose of the object if possible
   If obj IsNot Nothing AndAlso TypeOf obj Is IDisposable Then
      DirectCast(obj, IDisposable).Dispose()
   End If
   ' Decrease the reference counter, if it's a COM object
   If Marshal.IsComObject(obj) Then
      Marshal.ReleaseComObject(obj)
   End If
   obj = Nothing
End Sub

A questo punto, possiamo fare un "search and replace" in tutto il codice VB.NET prodotto dal wizard di migrazione, sostituendo le istruzioni var = Nothing con SetNothing.(var). Ovviamente, questo tecnica non risolve tutti i problemi menzionati in precedenza, perchè funziona solo con le variabili esplicitamente messe a Nothing via codice, e non quelle che sono azzerato implicitamente quando escono dallo scope corrente.

Poichè si tratta di una sostituzione con parti variabili, sembrerebbe che non sia possibile farlo in modo davvero automatico, e invece non è così, perchè possiamo usare le feature di ricerca e sostituzione di Visual Studio basate sulle regular expression. (Per maggiori info, vedere questo post.) Infatti, basta attivare la ricerca per regular expression, inserire la stringa <{:i} = Nothing come stringa da ricercare, e la stringa SetNothing(\1) come stringa di sostituzione. Et voilà

NOTA per i refrattari alle regex: la prima stringa dice di ricercare una variabile (:i) che si trova all'inizio di parola (<); le graffe in {:i} eseguono il tagging del nome dell'identificatore, in modo da poter poi usare il nome della variabile nel testo di sostituzione (mediante il placeholder \1). Tutto qui, non era mica difficile.

Il tipo Date di VB6 e il tipo Date di VB.NET (o il tipo System.DateTime di .NET, il che è lo stesso) sono molto simili, eccetto che per un dettaglio importante: in VB6 le date sono conservate internamente con valori Double, la cui parte intera rappresenta il numero di giorni trascorsi dal 30-12-1899 (non chiedetemi perchè non dal 31 dicembre...), e la cui parte decimale rappresenta le ore, minuti, e secondi sotto forma di frazione di giorno.

Il wizard che migra le applicazioni VB6 in VB.NET non modifica in alcun modo le variabili di tipo Date però deve tenere conto del fatto che i programma VB6 eseguono spesso operazioni con le date sfruttando il formato di memorizzazione interno. Ad esempio, ecco come in VB6 si calcola la data corrispondente a sette giorni dalla data odierna:

    Dim da As Date
    da = Now + 7
    MsgBox da

Per migrare correttamente le operazioni aritmetiche sulle date, il wizard usa i metodi FromOADate e ToOADate della classe Date, in questo modo:

   Dim da As Date
   da = Now
   da = System.Date.FromOADate(da.ToOADate + 7)

Non è un bel codice a vedersi, ma funziona. Anche in questo caso, però, è possibile applicare qualche trucchetto per ridurre al minimo le differenze sintattiche tra il codice VB6 e VB.NET e supportare l'aritmetica tra le date anche in VB.NET senza inserire nuovi metodi. Il meccanismo si basa sulla definizione di un nuovo tipo VB6Date, che conserva internamente un valore Date, che supporta le conversioni implicite da e verso i tipi Date, String, e Double, e che supporta anche gli operatori + e - con interi e Double:

<DebuggerDisplay("{DateValue}")> _
Public Structure VB6Date

   ' the origin of all dates
   Private Shared ReadOnly StartDate As Date = New Date(1899, 12, 30)

   ' this is where the actual date value is stored
   Private DateValue As Date

   ' private constructor (Friend to be visible from the VB6DateFunctions module)
   Friend Sub New(ByVal value As Date)
      Me.DateValue = value
   End Sub

   ' override the ToString method, to support Console.Write, etc.
   Public Overrides Function ToString() As String
      Return DateValue.ToString()
   End Function

   ' convert to/from Date values 
   Public Shared Widening Operator CType(ByVal value As VB6Date) As Date
      Return value.DateValue
   End Operator

   Public Shared Widening Operator CType(ByVal value As Date) As VB6Date
      Return New VB6Date(value)
   End Operator

   ' convert to/from Integer values 
   Public Shared Widening Operator CType(ByVal value As VB6Date) As Integer
      Return value.DateValue.Subtract(StartDate).Days
   End Operator

   Public Shared Widening Operator CType(ByVal value As Integer) As VB6Date
      Return New VB6Date(StartDate.Add(New TimeSpan(value, 0, 0, 0)))
   End Operator

   ' convert to/from Double values 
   Public Shared Widening Operator CType(ByVal value As VB6Date) As Double
      Return value.DateValue.Subtract(StartDate).Ticks / 864000000000
   End Operator

   Public Shared Widening Operator CType(ByVal value As Double) As VB6Date
      Return New VB6Date(StartDate.Add(New TimeSpan(CLng(value * 864000000000))))
   End Operator

   ' convert to/from strings 
   Public Shared Widening Operator CType(ByVal value As VB6Date) As String
      Return value.ToString()
   End Operator

   Public Shared Widening Operator CType(ByVal value As String) As VB6Date
      Return New VB6Date(Date.Parse(value))
   End Operator

   ' the + and - operators, with Integer and Double values
   Public Shared Operator +(ByVal value As VB6Date, ByVal days As Integer) As VB6Date
      Return New VB6Date(value.DateValue.Add(New TimeSpan(days, 0, 0, 0)))
   End Operator

   Public Shared Operator -(ByVal value As VB6Date, ByVal days As Integer) As VB6Date
      Return New VB6Date(value.DateValue.Subtract(New TimeSpan(days, 0, 0, 0)))
   End Operator

   Public Shared Operator +(ByVal value As VB6Date, ByVal days As Double) As VB6Date
      Return New VB6Date(value.DateValue.Add(New TimeSpan(CLng(days * 864000000000))))
   End Operator

   Public Shared Operator -(ByVal value As VB6Date, ByVal days As Double) As VB6Date
      Return New VB6Date(value.DateValue.Subtract(New TimeSpan(CLng(days * 864000000000))))
   End Operator

End Structure

Notate l'attributo DebuggerDisplay, che permette di visualizzare la data contenuta in un oggetto VB6Date quando si sposta il cursore del mouse sul nome di una variabile (solo in Visual Studio 2005).

Per completare l'effetto, occorre scrivere anche dei rimpiazzi per le funzioni Now, Date (ovvero Today in VB.NET), e Time, in modo che anche queste funzioni restituiscano un oggetto di tipo VB6Date:

Public Module VB6DateFunctions
   Public ReadOnly Property Now() As VB6Date
      Get
         Return New VB6Date(Microsoft.VisualBasic.DateAndTime.Now)
      End Get
   End Property

   Public ReadOnly Property [Today]() As VB6Date
      Get
         Return New VB6Date(Microsoft.VisualBasic.DateAndTime.Today)
      End Get
   End Property

   Public ReadOnly Property Time() As VB6Date
      Get
         Return New VB6Date(Now - Today)
      End Get
   End Property
End Module

A questo punto è possibile migrare il codice VB6 contenente operazioni aritmetiche sulle date semplicemente sostituendo il tipo della variabile che ospita tali valori:

' VB.NET code
Dim da As VB6Date    ' <-- the only modified statement
da = Now + 7
MsgBox(da)

Con questo esempio non sto certo suggerendo di cambiare TUTTE le vostre variabili Date per usare il tipo custom VB6Date. Il mio obiettivo principale è soprattutto di mostrare come - con un po' di fantasia e soprattutto sfruttando le nuove feature di VB2005, in questo caso l'overloading degli operatori - sia spesso possibile ridurre la distanza tra due linguaggi simili ma subdolamente differenti come VB6 e VB.NET. Ovviamente il discorso potrebbe valere anche nella migrazione in .NET da altri linguaggi ancora (ad esempio Java).

In chiusura, mi piacerebbe fare un piccolo sondaggio:

1) quanti di voi sviluppano o anche solo manutengono applicazioni VB6 ?
2) se si, perchè l'applicazione non è stata ancora convertita in VB.NET ?
3) in generale, quali ritenete siano gli ostacoli principali alla conversione ?
4) e quali sono i principali pregi e difetti del wizard di migrazione fornito con Visual Studio ?

Ciao a tutti, 
   vi riporto di seguito il calendario ufficiale dei prossimi webcast architetturali tenuti da Maurizio, Pierre, me ed altri. Il primo appuntamento e' domani. Illustrero' le novita' della rinnovata versione dell'Enterprise Library di Patterns & Practices per poi proseguire fino a giugno con una nutrita serie di argomenti e approfondimenti su tecnologie reali.

Quasi non ci speravo più, ma alla fine qualcuno è riuscito a risolvere il Quizzettone #9, ovvero come determinare una mano di poker in solo otto istruzioni. Anzi, il bravissimo Matteo Conta è riuscito a farlo in solo sette istruzioni. Graaaaande! Trovate la sua soluzione in coda ai vari commenti al post.

Come promesso, passo invece a illustrare la mia soluzione in otto istruzioni. La soluzione è in VB2005 (tratta dal nuovo libro Programming Microsoft Visual Basic 2005: The Language), ma potrebbe essere facilmente resa anche in C#:

Public Shared Function EvalPokerScore2(ByVal ParamArray cards() As String) As String
   ' Sort the array and create the sequence of values and of suits.
   Array.Sort(cards)
   Dim values As String = cards(0)(0) + cards(1)(0) + cards(2)(0) + cards(3)(0) + cards(4)(0)
   Dim suits As String = cards(0)(1) + cards(1)(1) + cards(2)(1) + cards(3)(1) + cards(4)(1)

   Dim scores(,) As String = { _
      {"12345|23456|34567|45678|56789|6789T|789JT|89JQT|9JKQT|1JKQT", "(.)\1\1\1\1", "StraightFlush"}, _
      {"(.)\1\1\1", ".", "FourOfAKind"}, _
      {"(.)\1\1(.)\2|(.)\3(.)\4\4", ".", "FullHouse"}, _
      {".", "(.)\1\1\1\1", "Flush"}, _
      {"12345|23456|34567|45678|56789|6789T|789JT|89JQT|9JKQT|1JKQT", ".", "Straight"}, _
      {"(.)\1\1", ".", "ThreeOfAKind"}, _
      {"(.)\1.?(.)\2", ".", "TwoPairs"}, _
      {"(.)\1", ".", "OnePair"}}
   For i As Integer = 0 To scores.GetUpperBound(0)
      If Regex.IsMatch(values, scores(i, 0)) AndAlso Regex.IsMatch(suits, scores(i, 1)) Then
         Return scores(i, 2)
      End If
   Next
   Return "HighCard"
End Function

(Nel computo delle istruzioni, non si conta nè End If nè Next, secondo le regole enunciate nel quiz...)

Per prima cosa il programma crea due stringhe, values contentente la sequenza dei valori delle carte, suits contenente la sequenza dei semi, poi definisce il vettore bidimensionale scores con le informazioni per cercare i vari punteggi. Ogni riga del vettore scores contiene due regular expression - una che viene applicata alla stringa values, l'altra alla stringa suits. Se entrambe le regex sono soddisfatte, il programma restituisce il terzo elemento della riga, ovvero il nome della combinazione. Notate che la seconda regex (quella che testa i colori) viene usata solo in due casi, per StraightFlush (scala reale) e Flush (colore), quindi in tutti gli altri casi basta usare la regex "." (qualsiasi carattere).

La maggior parte delle regex che testano i valori usano le cosiddette "backreference", ad es. "(.)\1\1" significa "cerca un carattere qualsiasi (il punto) poi ricercalo altre due volte (\1\1): il risultato della ricerca è positivo se vi sono tre carte uguali una dopo l'altra. Notare che l'array cards è ordinato rispetto al valore delle carte, quindi abbiamo la sicurezza che in values le carte con lo stesso valore sono adiacenti.

Proprio perche la stringa values è ordinata per valori, le regex da usare per testare le scale (StraightFlush e Straight) contengono dei caratteri apparentemente fuori ordine. Ad esempio, la scala massima si testa con la regex "1JKQT" e non con sequenza più intuitiva (ma errata), "TJQK1".

Concludendo, anche se la soluzione di Matteo è a dir poco sbalorditiva e assolutamente geniale, direi che quella basata su regex è decisamente più leggibile e manutenibile.

NOTA: Questa soluzione è in 8 istruzioni, ma ho spiegato che esiste anche la possibilità di scriverla in sole sette istruzioni. Questo si ottiene evitando di dividere le carte in due stringhe distinte (values e suits), ed usando invece una sola stringa data dalla concatenazione delle coppie (valore,seme). Anche in questo caso è possibile scrivere delle regex che trovano correttamaente tutte le combinazioni, ma le regex stesse sono molto più complesse, quindi ho deciso che nel libro avrei pubblicato questa versione più lunga ma più leggibile.

In realtà è persino possibile modificare il precedente codice per ottenere una soluzione in sole sei istruzioni: infatti, invece di creare le stringhe values e suits fuori dal ciclo, potrei crearle al volo ad ogni iterazione del ciclo For..Next. Non solo, ma se aggiungo una ulteriore riga alla matrice scores, contenente i sequenti valori:

         {".", ".", "HighCard"}}

Allora posso evitare anche l'istruzione Return finale, portando il totale a sole cinque istruzioni, anche se in quest'ultimo caso devo tenermi il warning che VB emette perchè non tutti i possibili percorsi della funzione restituiscono un valore. Insomma, se davvero volete scrivere codice illeggibile, non c'è che l'imbarazzo della scelta

Ultimissima nota: un pubblico ringraziamento e una pubblica lode anche a Paolo Possanzini, per essere stato il primo ad accanirsi e a risolvere, qualche mese fa mentre scrivevo il libro, questo quiz. Onore al merito!

Finalmente il mio ultimo librone è fisicamente disponibile su Amazon, e in un solo giorno è risalito di 8 mila posizioni in classifica: al momento in cui scrivo è alla posizione 1171, che è un ottimo piazzamento. Vi ricordo che sono disponibili altre informazioni sul libro, incluso un paio di capitoli di esempio in PDF, sulla home page che gestisco sul sito americano di dot-net-2-the-max.

Speriamo che anche l'analogo libro su C# e le classi base del Framework, di cui in questi giorni sto completando la revisione, abbia eguale fortuna...

Nel frattempo, il mio ultimo quizzettone è ancora insoluto, cosa insolita (ma non troppo, visto che questa volta era davvero tosto). Magari un aiutino ve lo posso dare: la mia soluzione in otto istruzioni si basa sulle regular expression e appare proprio nel capitolo sulle regex del libro in questione.

In questo periodo mi sto interessando molto ai problemi di migrazione delle applicazioni VB6 verso VB.NET. Personalmente non ho realmente "migrato" nessuna delle mie applicazioni, perchè ho sempre preferito riscriverle da zero per sfruttare al massimo le feature di .NET e soprattutto perchè il wizard di conversione fa un lavoro oggettivamente penoso, producendo un codice brutto e non manutenibile. O meglio, il wizard fa un lavoro decente, ma il vero problema sono le incompatiblità tra VB6 e VB.NET.

Alcune di queste incompatibilità, tuttavia, possono essere superate con un po' di fantasia, soprattutto ora che VB2005 offre delle feature che prima non erano disponibili. Prendiamo ad esempio il problema "classico" degli array con indice diverso da zero, che hanno fatto dannare tutti gli sviluppatori VB6 alle prese con il porting verso VB.NET. Supponiamo di avere il seguente codice VB6

      Dim arr(1 to 10) as Integer
      Dim i As Integer, prod As Integer, v As Variant
      For i = LBound(arr) To UBound(arr)
         arr(i) = i
      Next
      For Each v in arr
         prod = prod * v
      Next

Il wizard di conversione sostituirà l'indice iniziale 1 con l'indice 0, quindi l'array avrà un elemento in più. E' evidente che alla fine dell'esecuzione il valore di prod sarà zero, mentre avrebbe dovuto pari al fattoriale di 10!. Si tratta di errori molto subdoli, che costringono in pratica a ristudiare attentamente tutto il codice e a testare da zero l'applicazione. L'approccio manuale migliore è sicuramente quello di modificare la dichiarazione per "scalare" l'array in modo che il suo primo elemento reale abbia indice zero, e poi modificare TUTTI i riferimenti agli elementi dell'array, per tenere conto dello shift:

      Dim arr(0 to 10-1) as Integer     
      Dim i As Integer, prod As Integer
      For i = LBound(arr) To UBound(arr)
         arr(i - 1)  = i
      Next

Ma anche questo approccio richiede molta attenzione e in certi casi non puo' essere usato, ad esempio quando l'array viene passato a una procedura che deve funzionare con array di qualunque tipo (e il cui codice non sa che deve scalare l'indice); in altri casi ancora, il programma potrebbe prendere delle decisioni in base al valore di LBound e UBound, che nella nuova versione è modificato.

La domanda che mi sono posto è: è possibile convertire quel codice in VB2005 senza doversi preoccupare di tutti questi problemi? La soluzione è stata relativamente semplice, grazie ai generics e a qualche trucchetto con l'ereditarietà.

Public Class VBArrayBase
   Protected Friend lowerIndex As Integer
   Protected Friend upperIndex As Integer
End Class

Public Class VBArray(Of T)
   Inherits VBArrayBase
   Implements IEnumerable

   Dim items() As T

   Sub New(ByVal lowerIndex As Integer, ByVal upperIndex As Integer)
      Me.lowerIndex = lowerIndex
      Me.upperIndex = upperIndex
      ReDim items(upperIndex - lowerIndex)
   End Sub

   Default Property Item(ByVal index As Integer) As T
      Get
         Return items(index - lowerIndex)
      End Get
      Set(ByVal value As T)
         items(index - lowerIndex) = value
      End Set
   End Property

   Public Function GetEnumerator() As System.Collections.IEnumerator Implements System.Collections.IEnumerable.GetEnumerator
      Return items.GetEnumerator()
   End Function

End Class

Ci sono quizzettini relativamente semplici (come quelli che ho pubblicati negli ultimi mesi) e altre sfide logiche che richiedono un po' più di qualche secondo per essere risolti. Quello di oggi appartiene a questa seconda categoria, e merita quindi in pieno l'appellativo di QUIZZETTONE.

Il quesito è relativamente semplice: occorre scrivere un metodo EvalPokerScore in grado di determinare a quale punto del poker corrisponde una mano di cinque carte. Ciascuna carta è rappresentata da una stringa di due lettere, la prima delle quali rappresenta il valore della carta, a scelta tra le seguenti
       1, 2, 3, 4, 5, 6, 7, 8, 9, T (ten=dieci), J (jack), Q (queen), K (king)
la seconda lettera rappresenta ovviamente il seme, ed è una delle seguenti
       H (hearts=cuori), D (diamonds=quadri), S (spades=picche), C (clubs=fiori)

Il metodo EvalPokerScore deve restituire una stringa che indica il punto formato dalle cinque carte passate come argomento. Il risultato deve essere una delle stringhe seguenti
      "StraightFlush" (scala reale), "FourOfAKind" (poker), "FullHouse" (full), "Flush" (colore),
      "Straight" (scala), "ThreeOfAKind" (tris), "TwoPairs" (doppia coppia), "OnePair" (coppia), "HighCard" (nessun punto=carta più alta)

Notate che l'ordine dei punti è differente da quello che vi potreste aspettare: giocando al poker americano con tutte le 52 carte del mazzo, la probabilità e quindi il valore relativo di alcune combinazioni è differente da quello del poker come lo giochiamo dalle nostre parti. Ad esempio, il full batte sempre il colore. Ecco una lista di chiamate al metodo e il risultato atteso da ciascuna:

// These calls return "StraightFlush"
EvalPokerScore("1H", "2H", "3H", "4H", "5H");
EvalPokerScore("3H", "4H", "5H", "6H", "7H");
EvalPokerScore("6C", "7C", "8C", "9C", "TC");
EvalPokerScore("7S", "8S", "9S", "TS", "JS");
EvalPokerScore("8S", "9S", "TS", "JS", "QS");
EvalPokerScore("TD", "JD", "QD", "KD", "1D");
// These calls return "Flush"
EvalPokerScore("8S", "JS", "QS", "KS", "1S");
EvalPokerScore("7H", "8H", "9H", "TH", "KH");
EvalPokerScore("8C", "9C", "TC", "QC", "KC");
// These calls return "FourOfAKind"
EvalPokerScore("8C", "9D", "8D", "8H", "8S");
EvalPokerScore("TS", "TC", "QD", "TD", "TH");
EvalPokerScore("1C", "1S", "8S", "1H", "1D");
// These calls return "FullHouse"
EvalPokerScore("1C", "1D", "8C", "1D", "8S");
EvalPokerScore("9C", "9S", "8D", "8S", "9H");
EvalPokerScore("QC", "TD", "QD", "TS", "QS");
// These calls return "Straight"
EvalPokerScore("3S", "7S", "5S", "4S", "6D");
EvalPokerScore("6D", "7S", "8H", "9H", "TD");
EvalPokerScore("7S", "8D", "9D", "TH", "JC");
EvalPokerScore("TC", "JS", "QS", "KS", "1S");
// These calls return "ThreeOfAKind"
EvalPokerScore("9C", "9S", "8H", "TD", "9D");
EvalPokerScore("TC", "TS", "7S", "TH", "1D");
EvalPokerScore("TC", "TS", "8S", "TH", "KH");
// These calls return "TwoPairs"
EvalPokerScore("1C", "1F", "8F", "DP", "8Q");
EvalPokerScore("9C", "KF", "8F", "8P", "9Q");
EvalPokerScore("1C", "DF", "QF", "DP", "QQ");
// These calls return "OnePair"
EvalPokerScore("1C", "1H", "KH", "TS", "8S");
EvalPokerScore("9C", "KH", "QH", "8S", "9D");
EvalPokerScore("1S", "TS", "QC", "8C", "QC");
// These calls return "HighCard"
EvalPokerScore("1C", "QC", "KC", "TD", "8D");
EvalPokerScore("TC", "KC", "QD", "8D", "9H");
EvalPokerScore("1C", "TC", "KD", "8D", "QH");
EvalPokerScore("8D", "QD", "TD", "9D", "KH");

Scrivere il metodo EvalPokerScore non è proprio banale, ma neanche difficilissimo. Se siete in gamba potete risolverlo in una decina di minuti, se siete molto in gamba in cinque o meno. Ma adesso viene il bello: l'obiettivo del quizzettone non è solo di riuscire a risolvere il problema, ma di farlo con il minor numero di istruzioni possibile. Quindi

              Riuscite a scrivere il metodo EvalPokerScore con non più di otto istruzioni?

Nel conto delle istruzioni non è contaggiata la dichiarazione del metodo stesso. In altre parole:

// C#
public string EvalPokerScore( params string[] cards )
{
    // Non più di otto istruzioni qui
}

' VB
Public EvalPokerScore( ParamArray cards() As String ) As String
    ' Non più di otto istruzioni qui
End Function

Nel conteggio delle istruzioni, una istruzione corrisponde ad una assegnazione di variabile, chiamata a metodo e in generale a una sequenza di keyword che in C# sarebbe terminata con un punto-e-virgola e in VB con un newline oppure con il due-punti. Un blocco for, do, foreach, if corrisponde a una istruzione più quelle contenute nel blocco (questa precisazione è necessaria per non fare differenze tra C# e VB, poichè quest'ultimo richiede una keyword Next o EndIf per chiudere il blocco). Le graffe di apertura e chiusura blocchi in C# non sono conteggiate. Se si usa un anonymous delegates, occorre contare tutte le istruzioni nel metodo anonimo.

Se avete altre domande, lasciate pure un commento qui. Potete anche mandarmi le vostre soluzioni via email, se preferite, visto che potrebbe essere complicato formattarle a dovere (alcune istruzioni saranno necessariamente lunghe....)

Come ho anticipato, la soluzione non è proprio immediata nè semplice, però rappresenta quella che io chiamo "programmazione elegante". L'idea di questo quizzettone è tratta dal mio nuovo libro Programming Microsoft Visual Basic 2005: The Language, dove ovviamente mostro la soluzione e la spiego nei dettagli. Il tema del quizzettone è un ottimo esempio del codice a corredo del libro e esemplifica il concetto alla base del libro stesso, ovvero che conoscere la sintassi del linguaggio e delle classi base di .NET Framework è una cosa, sapere applicare queste nozioni è una cosa completamente differente, ed è questo che distingue uno sviluppatore davvero in gamba dagli altri. Come al solito, nessun premio in vile denaro al primo risolutore, ma solo imperitura fama sulle pagine di questo blog. NOTA: se otto istruzioni vi sembrano troppo poche, sappiate che è persino possibile farlo con sette, però a costo di complicare la struttura del codice. Meglio quindi una istruzione in più, ma mantenere l'eleganza del codice...

 

Ho già parlato in questo blog di CodeWall.NET, un tool per la protezione degli eseguibili .NET 2.0 dalla decompilazione, a cui io e Vito Plantamura stiamo lavorando da un paio di mesi. Finalmente abbiamo una beta robusta e funzionante, e non vediamo l'ora di metterla online.

Date le finalità del prodotto, non è un mistero il fatto che abbiamo passato la maggior parte del tempo per implementare tutte le tecniche "anti-sprotezione" di nostra conoscenza, incluso alcune davvero esoteriche. E' un vero peccato non poterle descrivere nei dettagli, per motivi che dovrebbero essere evidenti. Comunque, qualche cosa la posso comunque raccontare.

Uno dei punti deboli di praticamente tutti i meccanismi di protezione di questo tipo è che, se un "cracker" trova il modo per sproteggere UN SOLO eseguibile protetto, egli è in grado di scrivere uno script o un tool in grado di sproteggere TUTTI gli eseguibili protetti, la qual cosa sarebbe ovviamente un vero disastro per noi e per i nostri clienti. Per ovviare a questo serissimo problema, ogni copia di CodeWall.NET è unica. Non solo utilizza una chiave differente, ma contiene anche un algoritmo di decifratura leggermente differente. Questo accorginmento rende l'attacco mediante script virtualmente impossibile.

Ecco un'altra tecnica che abbiamo adottato per rendere la protezione più robusta. Le applicazioni protette con CodeWall.NET possono contenere delle stringhe criptate, che saranno riportate in chiaro solo in fase di esecuzione, e solo se l'assembly "gira" sotto CodeWall.NET. Questo significa che se anche qualcuno riuscisse a estrarre un assembly dall'eseguibile protetto, dovrebbe capire come funziona il decrypt delle stringhe e poi decrittare le stringhe una a una. Attenzione, perchè non solo è possibile criptare le stringhe in questo modo: è anche possibile criptare nomi di classi e di metodi, quindi se queste stringhe non sono decrittate correttamente il programma non funzionerebbe affatto.

Ovviamente, il loader di CodeWall.NET è scritto in codice unmanaged, in modo da NON essere decompilabile con Reflector, Anakrino, o ILDASM. Un malintenzionato particolarmente motivato potrebbe usare un disassembler "classico", ma poi gli toccherebbe decifrare migliaia di opcode assembly "nativo", il che non è proprio alla portata di tutti. Purtroppo, pero', l'uso del codice unamanged limita l'utilizzo di CodeWall.NET ai soli eseguibili Win32 (Windows Forms e Console) che girano in modalità full-trust. Non possiamo quindi supportare appliczioni ASP.NET e neanche applicazioni ClickOnce, a meno che questi ultimi non girino appunto in full-trust mode.

Non abbiamo ancora stabilito il prezzo di listino di CodeWall.NET, ma prevediamo che si aggirerà sui 250 dollari (circa 200 euro) e quasi certamente ci sarà uno sconto per il periodo del lancio. A breve speriamo di mettere una versione "trial" disponibile sul sito. Nel frattempo, se avete domande lasciate pure un commento.

Windows Communication Foundation (WCF) e Windows WorkflowFoundation possono essere utilizzati in un ambiente di produzione.

Ulteriori dettagli qui:

http://msdn.microsoft.com/winfx/getthebeta/golive/default.aspx

BIT e informazioni qui:

http://www.windowsworkflow.net

http://windowscommunication.net

Se potessi fare una survey istantanea, proverei a fare le seguenti due domande:

1. Il programma che usate più frequentemente è Visual Studio?
2. Avete mai usato le regular expression con il comando Find di Visual Studio?

Scommetterei che l'80% di voi risponderebbe SI alla prima domanda, ma che il 99% risponderebbe NO alla domanda successiva. Il che è alquanto bizzarro: stiamo parlando di una delle feature più potenzialmente utili dell'IDE eppure pochissimi la utilizzano o sanno addirittura che esiste.

Il vero problema è che la sintassi delle regular expression di Visual Studio è completamente differente da quella della classe Regex, quindi per usare questa feature occorrerebbe imparare un altro dialetto per le regular expression, e questo è troppo per la maggior parte degli sviluppatori. Microsoft dovrebbe usare le regex standard anche per questo comando: potrebbero farlo facilmente e in poco tempo, e senza creare problemi di compatibilità con i progetti esistenti.

In attesa che Microsoft si decida a fare questo piccola-grande innovazione, potete divertirvi con quello che avete a disposizione. Ecco alcuni esempi, tratti dal mio nuovo libro Programming Microsoft Visual Basic 2005: The Language:

:i = :z   Cerca nel codice le assegnazioni di un intero a una variabile. (:i sta per un qualsiasi identificativo, :z rappresenta una costante intera). In VB (ma non in C#) trova però anche dei false match, quando una espressione contiene un operatore di uguaglianza.

:i = :q   Cerca le assignazioni di una costante stringa (:q) a una variabile.

(Dim|Private|Public) :i As String   Cerca le dichiarazioni di variabili e field di tipo stringa (solo VB). E' facile adattarla ad altri tipi di dati.

Dim <(:Lu(:Ll)*)+> As   Cerca le dichiarazioni di variabili VB locali che usano un nome in PascalCase e che quindi violano le coding guideline di Microsoft (le variabli locali dovrebbero essere in camelCase)

^:b*'.+\n   Cerca le righe di commento in VB, ossia le righe che cominciano con apostrofo. (Non considera la keyword REM.) Sostituendo l'apostrofo con // si può usare questo pattern anche in C#

Dim {:i} As (.|\n)#<\1>    Evidenzia la porzione di codice tra la dichiarazione di una variabile locale e la prima occorrenza della variabile nel codice. Ripetendo questa ricerca in modo da matchare tutte le variabili locali in un metodo, si puo' controllare se vale la pena spostare la dichiarazione della variabile in modo da avvicinarla al suo primo utilizzo nel codice. (Vedi l'effetto in figura)

Incoraggiato dalle buone risposte al mio ultimo quizzettino sulla ottimizzazione, ne ho preparato un'altro sullo stesso tenore, anzi abbastanza simile, anche se credo sia abbastanza più semplice del precedente. Ma potro' dirlo solo dopo aver visto in quanto tempo lo risolverete (perchè oramai sono sicuro che lo risolverete, e presto!)

Supponiamo di avere un vettore bidimensionale di interi, e di voler calcolare il massimo della somma dei numeri in ciascuna colonna. Ecco il programma C# che risolve il problema

const int ROWS = 4000;
const int COLS = 4000;
int[,] arr = new int[ROWS, COLS];
// fill the array with random data (or read it from file, etc.)
Random rnd = new Random(1234);
for (int r = 0; r < ROWS; r++)
   for (int c = 0; c < COLS; c++)
      arr[r, c] = rnd.Next(1, 10000);
// eval the max of the sum of all elements in each given column
Stopwatch sw = Stopwatch.StartNew();
int sumMax = int.MinValue ;
for (int c = 0; c < COLS; c++)
{
   // eval the sum of elements in this column
   int colsum = arr[0,c];
   for (int r = 1; r < ROWS; r++)
      colsum += arr[r, c];
   // update the summax value
   if ( sumMax < colsum )
      sumMax = colsum;
}
Console.WriteLine(sw.ElapsedMilliseconds);
Console.WriteLine("Max is {0}", sumMax);       // Max is 20576003

In generale, penso che il namespace My di VB 2005 sia una bufala. Nei piani di Microsoft, questa nuova feature del linguaggio dovrebbe servire ad avvicinare i programmatori VB6 alla nuova versione, ma chiunque si è trovato a fronteggiare realmente la migrazione - del codice esistente o anche semplicemente della conoscenza - sa bene che non sono questi i motivi per cui il programmatori VB6 fanno ancora tanta resistenza a .NET. I veri problemi sono altri: il fatto che il wizard di traduzione non risolve tutti i problemi, il modello di ADO.NET così diverso da quello di ADO, e così via.

La mia impressione è che il namespace My non solo non servirà a conquistare nuovi convertiti alla religione .NET ma - cosa molto peggiore - servirà ad allontare qualche VB-ista dal "Verbo" del .NET Framework. Il namespace My non è che l'ennesimo strato che separa il linguaggio dal Framework vero e proprio. Avrebbero potuto farlo con una libreria di classi (e regalarla anche ai programmatori C#, poveretti!), invece hanno creato una infrastruttura che servirà a rendere il VB ancora una volta un linguaggio sui generis.

Quale sarà il risultato? secondo me, nel migliore dei casi saranno in pochi a usare questa feature, quindi alla fine non verrà estesa più di tanto. Nel caso peggiore, invece, molti programmatori VB, invece di studiare il .NET Framework e migliorare le loro conoscenze in materia, finiranno per usare questo strato che aggiunge poco o nulla e in alcuni casi addirittura offre meno flessibilità dell'accesso diretto alle classi del .NET Framework. Con l'aggravante che se vi fate viziare dal namespace My sarà più difficile passare a C# o a qualche altro linguaggio .NET.

In molti casi una chiamata a un metodo nel namespace My produce lo stesso effetto di una singola chiamata a un metodo del .NET Framework, quindi è lecito chiedersi perchè dovrei usare questa sovrastruttura se non porta alcun vantaggio, neanche a livello di maggiore concisione del codice? è una domanda ancora senza risposta. O meglio, il namespace My è una risposta a una domanda che in realtà nessuno ha mai fatto ... D'altra parte, Microsoft non fa queste cose alla leggera e sono certo che sono stati fatti focus group e sondaggi per misurare in anticipo l'indice di gradimento di questa feature. Bah, vedremo....

Ad essere obiettivo, comunque, nel namespace My ci sono delle cosucce davvero interessanti che vorrei tanto che fossero parte del Framework. Non che siano impossibili da ottenere altrimenti (ovviamente, visto che è comunque codice managed) ma la facilità con cui si ottengono con il namespace My è degna di nota. Ecco qualche esempio:

L'evento StartupNextInstance di My.Application: permette di sapere quando un'altra istanza della applicazione è stata lanciata e di leggere l'argomento passato sulla linea di comando. In questo modo si implementano applicazioni single-instance senza giochi strani con Mutex o altre tecniche non proprio semplicissime.

La collection OpenForms dell'oggetto My.Application: è comodo poter ciclare su tutti i form aperti nella applicazione senza dover scrivere il codice che mantiene sempre aggiornato l'elenco.

I metodi CopyDirectory, CopyFile, DeleteDirectory, DeleteFile, MoveDirectory e MoveFile dell'oggetto My.Computer.FileSystem: permettono di copiare, cancellare e spostare file e directory mostrando la dialog animata standard di Windows, senza dover usare PInvoke per chiamare la API ShFileOperation.

Il metodo FindInFile dell'oggetto My.Computer.FileSystem: cerca una stringa (opzionalmente in modo case-insensitive) in tutti i file di testo in un folder o un albero di directory, e restituisce la collection dei file che contengono la stringa. Lavorando con le regex si possono fare ricerche molto più sofisticate, ma questo metodo è molto più semplice da usare.

L'oggetto My.Computer.Keyboard: espone proprietà a sola lettura che testano lo stato dei tasti di shift e di lock, risparmiando una chiamata alle API di Windows.

I metodi DownloadFile e UploadeFile dell'oggetto My.Computer.Network: eseguono il download o l'upload di un file all'URL specificato, mostrando anche una dialog con il progress dell'operazione e segnalando se l'utente ha cancellato il comando.

A parte queste poche eccezioni - e qualcun'altra che potrebbe essermi sfuggita - non mi pare ci sia un reale vantaggio ad usare i metodi e gli oggetti del namespace My rispetto alle chiamate standard al Framework.

P.S. Non includo in questo elenco gli oggetti My.Resources e My.Settings, perchè anche se fanno parte del namespace My sono comunque a disposizione anche degli sviluppatori C#, anche se con una sintassi differente.

Ecco un altro quizzettino concettualmente molto semplice, ma la cui soluzione potrebbe fornire qualche buono spunto per ottimizzare le vostre applicazioni. Supponiamo di avere un array di numeri floating-point e di voler dividere tutti i valori del vettore per il valore minimo nel vettore stesso. Ecco una possibile soluzione in VB e in C#:

' VB
' An array of 10 million elements
Dim arr(9999999) As Double
' Fill it with random values.
Dim rnd As New Random(1234)
For i As Integer = 0 To arr.Length - 1
   arr(i) = rnd.NextDouble() * 1000000 + 100
Next
' Start the benchmark
Dim sw As Stopwatch = Stopwatch.StartNew()
' Find the min value.
Dim min As Double = arr(0)
For i As Integer = 1 To arr.Length - 1
   If min > arr(i) Then min = arr(i)
Next
' Divide all elements by the min value
For i As Integer = 0 To arr.Length - 1
   arr(i) /= min
Next
Console.WriteLine(sw.ElapsedMilliseconds)

// C#
// an array with 10 million elements
double[] arr = new double[10000000];
// fill it with random values.
Random rnd = new Random(1234);
for (int i = 0; i < arr.Length; i++)
   arr[i] = rnd.NextDouble() * 1000000 + 100;
// start the benchmark
Stopwatch sw = Stopwatch.StartNew();
// find the min value
double min = arr[0];
for (int i = 0; i < arr.Length; i++)
   if (min > arr[i]) min = arr[i];
// divide all elements by the min value
for (int i = 0; i < arr.Length; i++)
   arr[i] /= min;
Console.WriteLine(sw.ElapsedMilliseconds);

Il codice è davvero semplice, eppure è possibile ottimizzarlo ulteriormente in modo significativo, anche del 100% (ossia due volte più veloce). Come?

Visual Studio 2005 arriva con dozzine di code snippet già pronte all'uso. A dire il vero, potremmo discutere per un po' sulla qualità e l'utilità di qualcuna di queste, però ce ne sono molte davvero ben fatte. Io ad esempio uso in continuazione prop per creare proprietà pubbliche C# che "wrappano" variabili private.

La dialog box Code Snippet Manager (menu Tools) permette di ispezionare i vari snippets uno alla volta, ma stranamente non permette di creare una lista di tutti gli snippets installati, per cui uno deve guardarseli uno a uno e annotare nome, significato, e shortcut di tastiera. Mentre preparavo il capitolo 4 di Programming Microsoft Visual Basic 2005 ho scritto questo piccolo programmino usa-e-getta che decodifica l'indice degli snippets e gli elenca a video. Essendo una applicazion console, basta redirezionare l'output su file per creare un documento da usare come riferimento.

Il programma accetta in input il percorso del file SnippetIndex.xml (VB) o SnippetsIndex.xml (C#) che contiene l'indice degli snippet. (E' curioso che questo file abbia un nome differente nei due linguaggi.) Pero' lanciandolo senza argomenti utilizza il percorso di default dell'indice degli snippet VB. Un commento nel listato spiega come usare invece l'indice di default per C#.

L'output è molto spartano - solo il nome dello snippet e la sua shortcut, suddiviso in categorie - ma potete modificare facilmente il sorgente per estrarre e mostrare altri attributi. Anzi, se fate delle modifiche, mandatemele e le posto sul sito o sul blog.

Imports System.IO
Imports System.Xml
Imports System.Text.RegularExpressions

Module Module1
   Dim snippetsPath As String
   Dim catNames As New Dictionary(Of String, String)

   Sub Main(ByVal args() As String)
      ' If no argument has been provided, use default path for snippets.
      If args.Length = 0 Then
         args = New String() {"C:\Program Files\Microsoft Visual Studio 8\Vb\Snippets\1033\SnippetIndex.xml"}
         ' Uncomment next line to list C# snippets
         ' args = New String() {"C:\Program Files\Microsoft Visual Studio 8\VC#\Snippets\1033\SnippetsIndex.xml"}
      End If

      Dim snippetsFile As String = args(0)
      snippetsPath = Path.GetDirectoryName(snippetsFile)
      ' Load the snippet index file.
      Dim xmlIndex As New XmlDocument()
      xmlIndex.Load(snippetsFile)
      ' We need two passes, because dirs and subdirs use a different XML element.
      ParseSnippetIndex(xmlIndex, "//SnippetDir")
      ParseSnippetIndex(xmlIndex, "//SnippetSubDir")
      ' Iterate over all the directories in the main snippet directory.
      For Each dir As String In Directory.GetDirectories(snippetsPath)
         ParseSnippetFolder(dir, "")
      Next
   End Sub

   Sub ParseSnippetIndex(ByVal xmlIndex As XmlDocument, ByVal searchKey As String)
      ' Create the correspondence between relative paths and localized categories
      For Each xmlEl As XmlElement In xmlIndex.SelectNodes(searchKey)
         Dim elPath As XmlElement = DirectCast(xmlEl.SelectSingleNode("DirPath"), XmlElement)
         Dim elName As XmlElement = DirectCast(xmlEl.SelectSingleNode("LocalizedName"), XmlElement)
         catNames.Add(elPath.InnerText, elName.InnerText)
      Next
   End Sub

   Sub ParseSnippetFolder(ByVal dir As String, ByVal parentCategory As String)
      ' Retrieve the relative name of this subdirectory.
      Dim relPath As String = dir.Substring(snippetsPath.Length)
      ' The default name for this category
      Dim categoryName As String = parentCategory & Path.GetFileNameWithoutExtension(dir)
      ' Search this relative path in the snippet index.
      Dim searchPath As String = "%InstallRoot%\Vb\Snippets\%LCID%" + relPath + "\"
      If catNames.ContainsKey(searchPath) Then
         ' If found, use the localized category as appears in the index file
         categoryName = parentCategory & catNames(searchPath)
      End If
      Console.WriteLine(categoryName.ToUpper())
      ' Parse individual snippets in this directory.
      For Each file As String In Directory.GetFiles(dir, "*.snippet")
         ParseSnippetFile(file)
      Next
      ' Parse all sub-categories
      For Each subdir As String In Directory.GetDirectories(dir)
         ParseSnippetFolder(subdir, categoryName & " / ")
      Next
   End Sub

   Dim reTitle As New Regex("<Title>(.+?)</Title>")
   Dim reShortcut As New Regex("<Shortcut>(.+?)</Shortcut>")

   Sub ParseSnippetFile(ByVal snippetFile As String)
      Dim text As String = File.ReadAllText(snippetFile)
      ' We use regexes to extract information for individual snippet files.
      Dim maTitle As Match = reTitle.Match(text)
      Dim maShortcut As Match = reShortcut.Match(text)
      Dim title As String = maTitle.Groups(1).Value
      Dim shortcut As String = maShortcut.Groups(1).Value
      Console.WriteLine(" {0} [{1}]", title, shortcut)
   End Sub
End Module

Anche oggi un quizzettino davvero facile, anzi banale, tanto per scaldarci i neuroni in vista della WPC. Considerate questo codice VB2003 che converte gli elementi di un vettore di interi in un array di stringhe contentente la rappresentazione esadecimale di ciascun elemento

Dim intArray() As Integer = { 4, 6, 9, 10, 99, 233, 34, 88, 189}   ' ecc ecc.
Dim hexArray(intArray.Length - 1) As String
For i As Integer = 0 To intArray.Length - 1
   hexArray(i) = intArray(i).ToString("X")
Next

La domanda è: qual'è il numero minimo di istruzioni C# 2.0 o VB2005 che occorre scrivere per ottenere lo stesso risultato?

Nota per i C# 2.0: le istruzioni negli anonymous method vanno contate a parte. Quindi, una istruzione che usa un anonymous method che contiene uno statement conta come due istruzioni.

Oggi stavo rivedendo il capitolo sui tipi base di .NET, in particolare sul boxing e unboxing, e ho guardato con più attenzione il seguente codice:

' The version that does NOT cache the value type in a reference variable.
Dim start As Date = Now
For i As Integer = 1 To 1000
   For j = 1 As Integer To 100000
      GetObject(i, j)
   Next
Next
Console.WriteLine("Version 1: " & Now.Subtract(start).ToString)
GC.Collect() : GC.WaitForPendingFinalizers()

' The version that caches the value type in a reference variable.
start = Now
For i = 1 As Integer To 1000
   ' Cache the value type in an Object variable.
   Dim o As Object = i
   For j As Integer = 1  To 100000
      GetObject(o, j)
   Next
Next
Console.WriteLine("Version 2: " & Now.Subtract(start).ToString)

Private Function GetObject(ByVal o As Object, ByVal o2 As Object) As Object
   Return o
End Function

Come indicano i commenti, la seconda parte del codice "ottimizza" l'esecuzione conservando in una variabile Object la versione boxed del contatore i, che non varia all'interno del ciclo piu' interno. C'è da aspettarsi che la seconda versione dei due cicli sia più veloce, anche se di poco, e infatti questo è quello che accade con Visual Basic .NET 2003. Per fortuna ho rifatto tutti i test con la nuova versione e mi sono accorto che in VB2005 le cose non stanno cosi': per quanto possa sembrare poco intuitivo, la versione che esegue il cache della variable boxed è il 30-40% più lenta dell'altra!

Per capire cosa accade ci vuole un po' di ILDASM, grazie al quale si vede che ogni volta che VB, prima di passare una variabile Object a un argomento Object, chiama il metodo GetObjectValue della classe RuntimeHelpers (namespace System.Runtime.CompilerServices). Questo spiega l'overhead osservato. La cosa strana è che questa chiamata è generata anche in VB2003, eppure non ribalta le conclusioni del benchmark. Poichè sto lavorando con la RTM ne deduco che l'overhead è reale (e non dovuto a pezzi di codice del CLR compilato in debug mode) quindi l'unica conclusione possibile, per il momento, è che la versione 2.0 del metodo GetObjectValue sia meno efficiente della versione 1.1.

Mi sono chiesto cosa faccia GetObjectValue esattamente, ma non mi sono spinto a usare Anakrino per disassemblare quella parte. Immagino che quella chiamata - che è generata dal compilatore VB ma non da C# - serva a compensare il fatto che in VB sono possibili chiamate late-bound e che quella variabile potrebbe anche conservare un pointer a un oggetto COM. Un giorno risolverò i miei dubbi, ma per adesso starò bene attento a eseguire sempre dei benchmark accurati prima di "ottimizzare" il mio codice in questo modo.

UPDATE: Come potete leggere nei commenti, mentre io mi chiedevo cosa facesse GetObjectValue, c'era Adrian Florea che già da tempo aveva scovato dei commenti nei sorgenti di Rotor che chiarivano il mistero. Ecco il suo post, che spiega tutto.

Sto revisionando il 3° capitolo sul controllo del flusso, e ho pensato di mettere in forma di quiz un piccolo tip che spiego nel libro. Considerate il seguente codice:

For i As Integer = 1 To 10
   Dim exiting As Boolean = False
   For j As Integer = 1 To 20
      ' If the Evaluate function returns zero you want to exit both loops
      If Evaluate(i, j) = 0 Then
         exiting = True
         Exit For
      End If
   Next
   If exiting Then Exit For
Next

Qualche settimana fa scrivevo un post a proposito della covarianza e controvarianza dei delegate in C# 2.0, stupendomi del fatto che in giro per la rete in tanti parlano di queste nuove feature ma senza spiegare a cosa possono servire realmente.

Poichè tutti gli eventi .NET sono gestiti mediante delegate, grazie alla controvarianza è possibile che un unico metodo possa gestire più eventi del tipo (sender, e). anche se la loro signature è leggermente differente. Supponiamo di avere questo metodo:

   Sub GestoreEvento(ByVal sender As Object, ByVal e As EventArgs) 
      ..   
   End Sub

Un metodo di questo tipo è in grado di gestire tutti gli eventi del tipo (sender, e), anche se il secondo argomento non è un EventArgs ma un tipo che eredita da EventArgs. Quindi un metodo di questo tipo è in grado di gestire virtualmente tutti gli eventi definiti nel .NET Framework, con pochissime eccezioni. (L'evento AppDomain.AssemblyResolve è una di queste eccezioni, perchè non è un metodo Sub ma una Function che restituisce un oggetto Assembly.)

Anche se la controvarianza permette in teoria di far gestire tutti gli eventi di un oggetto da un unico metodo, nella pratica le cose sono un po' più complicate, perchè il metodo GestoreEvento ha modo di sapere quale oggetto sta scatenando l'evento (tramite l'argomento sender) ma non quale evento è stato scatenato. Per ottenere questa informazione occorre scrivere del codice un po' più complesso.

Insomma, alla fine ho scritto un componente EventInterceptor che potete sistemare sulla superficie di un Windows Forms e che vi permette di catturare tutti (o alcuni) eventi di un controllo sul form (o al limite di tutti i controlli sul form) per mezzo di un unico gestore. Trovate l'articolo e il codice sorgente a corredo a questo link.

Come anticipavo in un precedente post, ecco il sommario definitivo del librone. Anzi del "libretto", visto che con solo 800 pagine è decisamente al di sotto dei miei standard

Part I : The Basics
 1. Introducing the .NET Framework (30 pag.): una veloce carrellata dei concetti più importanti della programmazione per .NET
 2. Basic Language Concepts (64 pag.): moduli, classi, variabili, array, operatori, ecc. con il minimo che serve sapere sulla ereditarietà e gli attributi per comprendere i capitoli che seguono prima del cap. 8 e 19.
 3. Control Flow and Error Handling (36 pag.): istruzioni base come If, Select, For, For Each, ecc. e gestione degli errori, con numerose tecniche poco note per migliorare l'efficienza del codice e il proprio stile di programmazione.
 4. Using Visual Studio 2005 (50 pag.): le tantissime novità dell'IDE e anche molte vecchie feature che non tutti conoscono; come scrivere un code snippet per VS2005, i template, le funzioni di refactoring, e soprattutto un breve ma "succoso" tutorial sulle macro.
 5. Debugging and Testing (46 pag.): breakpoint e tracepoint, data tip, scrivere un visualizer, le funzioni di trace e relativi trace listeners (incluso custom listeners), benchmark e profiling, unit testing e code coverage, ecc.

Part II : Object-Oriented Programming
 6. Class Fundamentals (36 pag.): la "solita storia" su classi, metodi, proprietà, ecc. ma anche le nuove partial class e l'overloading degli operatori, il tutto condito da alcune tecniche di programmazione meno diffuse.
 7. Delegates and Events (24 pag.): un capitolo piccolo con numerosi dettagli su come sfruttare al meglio, nei programmi "reali", queste due feature di VB, incluso i nuovi eventi custom
 8. Inheritance (32 pag.): l'ereditarietà spiegata come meglio non potrei, inclusa l'ereditarietà visuale dei form, con numerosi esempi reali.
 9. Object Lifetime (26 pag.): tutto quello che potreste voler sapere su garbage collection, Dispose e Finalize, weak reference, generation, object resurrection, e altre tecniche in grado di moltiplicare le prestazioni delle applicazioni .NET che usano (male) la memoria.
10. Interfaces (26 pag.): costruire una interfaccia custom e soprattutto usare al meglio quelle che fornisce .NET, incluso IComparer e IEnumerable.
11. Generics (30 pag.): metà di quello che c'è da sapere su questa grande feature di .NET 2.0 (l'altra metà nel capitolo 13), incluso constraints e nullable types e soprattutto tanti esempi e tecniche di programmazione basate sui generics

Part III : Working with the .NET Framework
12. .NET Basic Types (44 pag.): lavorare al meglio con stringhe, numeri e date, incluso alcune piccole/grandi novità introdotte con .NET 2.0
13. Arrays and Collections (48 pag.): array, jagged array, collection "tradizionali" e collection generics, con tanti piccoli tricks in grado di ridurre la quantità di codice a aumentare le prestazioni.
14. Regular Expressions (40 pag.): tutta la sintassi ma anche tantissimi esempi pratici, su come validare i dati, eseguire il parsing di file di testo e persino del codice. Se non conoscete le regex vi perdete innumerevoli possibilità di scrivere codice più compatto e veloce...
15. Files and Streams (38 pag.): una carrellata sui tipi in System.IO e le nuove (tante) feature in .NET 2.0, tra cui il supporto per ACL e la classe TextFieldParser.
16. The My Namespace (40 pag.): come usare questa feature VB-only per scrivere codice in modo più semplice, ma anche come estendere il namespace My a proprio piacimento
17. Assemblies and Resources (44 pag.): nonostante la loro importanza, le risorse (localizzabili o meno) sono usate poco e male dalla maggioranza dei programmatori; il capitolo include anche una completa descrizione delle nuove importantissime feature di NGEN

Parti IV : Advanced Topics
18. Reflection (54 pag.): su reflection c'è tantissimo da dire, mi viene quasi voglia di scriverci un libro. Tra gli esempi ce n'è uno che genera codice "al volo", uno scheduler di azioni (con tanto di undo), e un comparer universale.
19. Custom Attributes (42 pag.): contiene alcuni esempi anche complessi di come un custom attribute può semplificare i propri programmi, ad es. per creare plug-in per Windows Forms e un framework per applicazioni n-tier.
20. Threads (48 pag.): l'oggetto Thread, i delegate asincroni, il thread pool, l'istruzione SyncLock, tutte le classi per la sincronizzazione, incluso i nuovi Semaphore, i problemi del multithreading nella applicazioni Windows Forms. Insomma, come scrivere applicazioni che usano thread multipli senza pentirsi di averci provato...
21. Object Serialization (30 pag.): serializzazione binaria, la serializazzione version-tolerant di .NET 2.0, i nuovi attributi per la serializzazione, serializzazione custom, i serialization surrogate, l'interfaccia IObjectReference, e altro ancora

Appendix
A: Migrating from Visual Basic 6 (24 pag.) a beneficio di chi arriva a VB2005 direttamente da VB6, un riassunto di tutte differenze tra i due linguaggi e dei controlli per la interfaccia utente (ovviamente solo WinForm, visto che in VB6 non esiste un analogo di asp.net).

I numeri delle pagine in ciascun capitolo sono ovviamente indicativi. Per queste stime ho costruito un foglio Excel che calcola il numero stimato di pagine partendo dalla dimensione dei file word, il numero di tabelle e figure, ecc.

La cifra caratteristica del libro è che, a dispetto del titolo, non è un semplice reference sul Visual Basic 2005. O meglio, oltre ad essere un completissimo reference, è un vero e proprio manuale di tecniche di programmazione basate sulle feature sia del linguaggio che del .NET Framework, tra cui i generics, multi-threading, reflection, custom attribute, serializzazione, delegate, regular expression, ed altro ancora. Il tutto con un occhio alla flessibilità e alla robustezza del codice, e ovviamente alla sua efficienza. Non credo di esagerare nel dire che non ho mai trovato qualcosa del genere in giro e che ho davvero scritto il libro che ho sempre desiderato scrivere, che rende finalmente giustizia a Visual Basic e alle feature di basso livello di .NET più in generale.

E' stato un bel tour de force, visto che ci lavoro da Maggio, estate compresa. Al momento sto completando gli ultimi capitoli, poi farò un'ultima revisione con la RTM per controllare che non ci siano sorprese, visto che tra Beta 2 e RC ce ne sono state un bel po'. (Un consiglio interessato: non fidatevi dei libri su .NET 2.0 che trovate in libreria a novembre, non possono essere aggiornati neanche alla RC, figuriamoci al prodotto finale...)

Poi finalmente si va in stampa! Se tutto va bene, dovrebbe essere nelle librerie americane a Dicembre o i primi di Gennaio. Ottimo regalo da chiedere a Babbo Natale, o al più tardi alla Befana

Un quiz di Adrian Florea mi ha ricordato una tecnica che uso talvolta per evitare chiamate ricorsive a un metodo. La tecnica "classica" per evitare la ricorsione consiste nel definire un campo booleano a livello di classe e testarlo all'entrata del metodo. Questa tecnica è spesso usata negli eventi di tipo TextChanged che modificano a loro volta la proprietà Text di un controllo, e che quindi farebbero scattare una ricorsione infinita:

Dim insideTextChanged As Boolean

Private Sub TextBox1_TextChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles TextBox1.TextChanged
   ' Exit if this is a recursive call.
   If insideTextChanged Then Exit Sub
   ' Forbid recursive calls from now on.
   insideTextChanged = True
   ' ...
   TextBox1.Text = TextBox1.Text & " "
   ' Permit recursive calls.
   insideTextChanged = False
End Sub

Questo approccio funziona, ma è decisamente scomodo perchè richiede un bel po' di codice. Se poi esiste anche la minima possibilità che possa avvenire una eccezione, allora occorre che tutto il corpo del metodo sia avvolto in un blocco Try, che imposta insideTextChanged a False nella sezione Finally. Perchè non usare allora una funzione che permette di testare se siamo all'interno di una chiamata ricorsiva? Penso ad esempio a qualcosa di questo tipo:

Private Sub TextBox1_TextChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles TextBox1.TextChanged
   ' Exit if this is a recursive call.
   If IsRecursive() Then Exit Sub
   ' ...
   TextBox1.Text = TextBox1.Text & " "
End Sub

Ecco come implementare la funzione IsRecursive:

<System.Runtime.CompilerServices.MethodImpl(Runtime.CompilerServices.MethodImplOptions.NoInlining)> _
Public Shared Function IsRecursive() As Boolean
   Dim st As New StackTrace
   ' Check whether any method in the call stack is the same as the immediate caller.
   For n As Integer = 2 To st.FrameCount - 1
      If st.GetFrame(1).GetMethod() Is st.GetFrame(n).GetMethod() Then Return True
   Next
   Return False
End Function

Ecco la versione C#:

[System.Runtime.CompilerServices.MethodImpl(Runtime.CompilerServices.MethodImplOptions.NoInlining)]
public static bool IsRecursive() 
{
   StackTrace st = new StackTrace();
   // Check whether any method in the call stack is the same as the immediate caller.
   for ( int n= 2; n < st.FrameCount; n++ )
   {
      if ( st.GetFrame(1).GetMethod() == st.GetFrame(n).GetMethod() ) 
         return true;
   }
   return false;
}

Il metodo controlla il metodo del chiamante immediato - ossia st.GetFrame(1).GetMethod() - con il metodo di tutti gli altri chiamanti sullo stack, e restitusce True se trova un match. E' essenziale che il metodo IsRecursive sia marcato con l'attributo MethodImpl in modo da evitare che il JIT-compiler esegua l'inline del metodo e faccia saltare il meccanismo di controllo. Nella versione attuale del JIT compiler questo problema non dovrebbe mai accadere, perchè il JIT compiler non esegue l'inlining dei metodi che contengono un loop, ma per il futuro non si puo' mai dire, e questo attributo ci mette al riparo da sorprese. Per lo stesso motivo, non si dovrebbe chiamare IsRecursive da un metodo che potrebbe essere ottimizzato mediante inlining.

Per chi non lo sapesse, l'inlining è una tecnica di ottimizzazione grazie alla quale il JIT-compiler riesce a spostare il codice di un metodo direttamente nel codice del metodo chiamante, in modo da evitare una istruzione di chiamata. Solo metodi molto piccoli, 32 byte di IL o meno, che non hanno cicli o loop, e che non accettano dei value type come argomenti possono essere ottimizzati in questo modo, nella versione attuale del JIT compiler, quindi nella pratica l'inlining avviene in pochi casi, tipicamente per le proprietà che wrappano una variabile e per i metodi con al massimo 2-3 righe di codice.

In un post del maggio scorso mi lamentavo del fatto che in Visual Studio 2005, scrivendo Implements IDisposable nella dichiarazione di una classe si otteneva il pattern Dispose-Finalize completo. Un sacco di codice, ma soprattutto un codice sbagliato, in quanto una classe disposable in genere NON deve implementare il metodo Finalize, in quanto il metodo Finalize serve solo se la classe crea e utilizza risorse unmanaged.

Le classi dotate di Finalize richiedono qualche ciclo di CPU in più durante l'istanziazione, ma questo non era il problema principale a mio avviso. Il fatto che Visual Studio creasse automaticamente codice errato mi dava un fastidio quasi fisico: chi avrà mai preso questo decisione a Redmond?

Beh, evidentemente non sono stato l'unico a lamentarsi, perchè ho appena scoperto - con molto piacere - che questa "feature" è stata rimossa nella CTP di Agosto (e immagino anche nella RC). Ora quando digitate Implements IDisposable, VS2005 risponde creando il codice seguente:

Class FooBar
   Implements IDisposable

   Private disposedValue As Boolean = False ' To detect redundant calls

   ' IDisposable
   Protected Overridable Sub Dispose(ByVal disposing As Boolean)
      If Not Me.disposedValue Then
         If disposing Then
            ' TODO: free unmanaged resources when explicitly called
         End If
         ' TODO: free shared unmanaged resources
      End If
      Me.disposedValue = True
   End Sub

#Region " IDisposable Support "

   ' This code added by Visual Basic to correctly implement the disposable pattern.
   Public Sub Dispose() Implements IDisposable.Dispose
      ' Do not change this code. Put cleanup code in Dispose(ByVal disposing As Boolean) above.
      Dispose(True)
      GC.SuppressFinalize(Me)
   End Sub

#End Region
End Class

E' bello, una volta tanto, poter dire a posteriori "lo avevo detto io!"

Per prima cosa, un po' di background su cosa è la covariance e la contravariance dei delegate in C# 2.0. Supponiamo di avere un delegate di questo tipo:

   delegate object GetControlData(TextBox ctrl);

Per covariance si intende il fatto che è possibile fare puntare il delegate a un metodo il cui valore di ritorno eredita dal tipo di valore di ritorno specificato dal delegate. Ad esempio, poichè il delegate GetControlData restituisce un object, la covarianza permette di fare puntare il delegate a qualsiasi metodo, indipendentemente dal tipo di oggetto restituito, purchè il metodo accetti un oggetto TextBox in input. L'unica condizione è che il metodo restituisca effettivamente qualcosa, quindi non posso fare puntare il delegate a un metodo void. Ad esempio, potrei creare un oggetto GetControlData che punta a questo metodo, poichè il tipo string deriva da object:

   string GetText(TextBox ctrl) 
   { return ctrl.Text; }

Supponete ad esempio di avere un componente nel data tier che contiene la stringa di connessione al database. Questa stringa di connessione è letta al momento di istanziare il componente - ad esempio da un file di configurazione XML - e quindi il compilatore non può memorizzarla nell'intern pool. Se questo componente è istanziato N volte vi saranno N copie della stringa di connessione in memoria, il chè costituisce uno spreco di memoria se la stringa è lunga e N è molto alto. Ci sono due modi per evitare questo spreco, a seconda di come la stringa di connessione può variare.

Se la stringa di connessione è esattamente la stessa per tutte le istanze allora la si può conservare in una variabile statica (Shared in VB), in modo che un'unica stringa è condivisa tra tutte le istanze del componente. Questo è il caso più semplice e non credo valga la pena approfondirlo ulteriormente.

Se invece la stringa di connessione può variare - per esempio, se usate un unico tipo le cui istanze possono collegarsi a due o più differenti database - non è possibile usare una variabile static, ma si può ricorrere ad una tecnica basata sul metodo String.Intern. Questo metodo riceve un argomento stringa e lo ricerca nell'intern pool: se la stringa è nel pool, il metodo restituisce un riferimento all'elemento esistente; se la ricerca fallisce, il metodo inserisce la stringa nel pool e restituisce un riferimento all'elemento appena aggiunto. Ecco come si potrebbe implementare la proprietà ConnectionString nell'ipotetico data object per sfruttare il pool di stringhe:

// C#
private string m_ConnectionString;

public string ConnectionString
{
  get { return m_ConnectionString; }
  set { m_ConnectionString = String.Intern(value);}
}

La prima volt ache un certo valore è assegnato alla proprietà ConnectionString, la ricerca nel pool fallisce, il metodo String.Intern aggiunge la stringa al pool e restituisce un riferimento al nuovo elemento del pool. Se la stessa stringa di connessione è assegnata a una istanza differente del data object, il metodo String.Intern restituisce un riferimento all'elemento che è già nel pool e non è creato alcun duplicato. In questo modo la quantità di memoria complessiva usata dal componente è minore e si riduce anche il numero delle garbage collection necessarie. 

Sto aggiustando il capitolo sul controllo del flusso di esecuzione, dove parlo (tra le variecose) anche delle funzioni ricorsive. Nella maggior parte dei libri di programmazione che conosco (incluso molti "classici") la ricorsione è trattata in modo superficiale con il tipico esempio del fattoriale (che può essere risolto in modo più efficiente con un ciclo For) oppure per visitare strutture ad albero. Sembrerebbe che la ricorsione non serva in una applicazione gestionale "normale", il che ovviamente non è vero. Come tutte le tecniche di programmazione, basta essere attenti a sfruttare le occasioni.

Ecco ad esempio un metodo che trasforma un numero nel suo corrispondente alfanumerico (ad es. 1234 in "One Thousand Two Hundreds Thirty Four"). Il codice è preso dal libro per Microsoft Press e quindi il risultato è in inglese, ma è facile ottenere una versione che emette il risultato in italiano:

Function NumberToText(ByVal n As Integer) As String
   Select Case n
      Case Is < 0
         Return "Minus " & NumberToText(-n)
      Case 0
         Return ""
      Case 1 To 19
         Dim arr() As String = {"One", "Two", "Three", "Four", "Five", "Six", _
            "Seven", "Eight", "Nine", "Ten", "Eleven", "Twelve", "Thirteen", _
            "Fourteen", "Fifteen", "Sixteen", "Seventeen", "Eighteen", "Nineteen"}
         Return arr(n - 1) & " "
      Case 20 To 99
         Dim arr() As String = {"Twenty", "Thirty", "Forty", "Fifty", "Sixty", _
            "Seventy", "Eighty", "Ninety"}
         Return arr(n \ 10 - 2) & " " & NumberToText(n Mod 10)
      Case 100 To 199
         Return "One Hundred " & NumberToText(n Mod 100)
      Case 200 To 999
         Return NumberToText(n \ 100) & "Hundreds " & NumberToText(n Mod 100)
      Case 1000 To 1999
         Return "One Thousand " & NumberToText(n Mod 1000)
      Case 2000 To 999999
         Return NumberToText(n \ 1000) & "Thousands " & NumberToText(n Mod 1000)
      Case 1000000 To 1999999
         Return "One Million " & NumberToText(n Mod 1000000)
      Case 1000000 To 999999999
         Return NumberToText(n \ 1000000) & "Millions " & NumberToText(n Mod 1000000)
      Case 1000000000 To 1999999999
         Return "One Billion " & NumberToText(n Mod 1000000000)
      Case Else
         Return NumberToText(n \ 1000000000) & "Billions " _
            & NumberToText(n Mod 1000000000)
   End Select
End Function

Ecco la versione per gli amanti delle parentesi graffe. Poichè lo switch di C# non supporta i range, ho dovuto modificare il codice per usare una serie di istruzioni elseif. Un dettaglio interessante è come il codice costruisce un array di stringhe al volo per poi selezionare un elemento. E' possibile farlo anche in VB.NET, ma è una di quelle feature che piacciono soprattutto ai programmatori C#:

string NumberToText( int n)
{
   if ( n < 0 )
      return "Minus " + NumberToText(-n);
   else if ( n == 0 )
      return "";
   else if ( n <= 19 )
      return new string[] {"One", "Two", "Three", "Four", "Five", "Six", "Seven", "Eight", "Nine", "Ten", "Eleven", "Twelve", "Thirteen", 
         "Fourteen", "Fifteen", "Sixteen", "Seventeen", "Eighteen", "Nineteen"}[n-1] + " ";
   else if ( n <= 99 )
      return new string[] {"Twenty", "Thirty", "Forty", "Fifty", "Sixty", "Seventy", "Eighty", "Ninety"}[n / 10 - 2] + " " + NumberToText(n % 10);
   else if ( n <= 199 )
      return "One Hundred " + NumberToText(n % 100);
   else if ( n <= 999 )
      return NumberToText(n / 100) + "Hundreds " + NumberToText(n % 100);
   else if ( n <= 1999 )
      return "One Thousand " + NumberToText(n % 1000);
   else if ( n <= 999999 )
      return NumberToText(n / 1000) + "Thousands " + NumberToText(n % 1000);
   else if ( n <= 1999999 )
      return "One Million " + NumberToText(n % 1000000);
   else if ( n <= 999999999)
      return NumberToText(n / 1000000) + "Millions " + NumberToText(n % 1000000);
   else if ( n <= 1999999999 )
      return "One Billion " + NumberToText(n % 1000000000);
   else 
      return NumberToText(n / 1000000000) + "Billions " + NumberToText(n % 1000000000);
}

Non è codice complesso, ma non ho mai visto sui mille siti Internet una routine per la trasformazione di numeri in lettere altrettanto concisa ed efficace. Adoro la programmazione ad oggetti, i generics, gli attributi, e le regular expression, ma mi piace ricordare (e ricordarmi) che spesso si può scrivere ottimo codice, compatto e veloce, anche solo sfruttando feature che i principali linguaggi hanno da venti o trent'anni.

Com'è noto, Visual Studio 2005 include un designer per creare automaticamente una classe My.Settings, che contiene le impostazioni sia a livello di applicazione che di utente. Anche se il designer è decisamente comodo, non è chiaro perchè usare un designer debba essere più semplice che scrivere una classe che esponga quelle impostazioni sotto forma di campi e proprietà, che le carichi automaticamente da disco e che, se modificate, le salvi automaticamente al momento di chiudere l'applicazione. Dal mio punto di vista, l'approccio scelto da Microsoft per VS2005 è la (solita?) esasperazione del concetto RAD, solo che in questo caso le operazioni necessarie per definire la classe My.Settings non fanno in realtà risparmiare tempo rispetto alla definizione via codice delle stesse entità.

Queste considerazioni mi sono venute spontanee non ragionando in astratto, ma mentre scrivevo le mie prime applicazioni.NET 2.0. Avevo necessità di un meccanismo per salvare tutte le impostazioni del programma in un file, un po' come quando in Visual Studio salviamo tutte le impostazioni di un progetto in un file .sln. A pensarci bene, il problema è simile (o meglio, identico) al problema di salvare le impostazioni relative all'utente e alla applicazione: si tratta di salvare e poi ricaricare un gruppo di variabili su disco, con la differenza che nel caso delle impostazioni di progetto la posizione del file non è fissa.

Insomma, alla fine ho scritto un meccanismo di persistenza per le variabili di progetto, basato su una classe base SettingsBase. Quando ho una serie di variabili globali in un progetto che devono essere salvate e ricaricate su richiesta, non devo fare altro che derivare una classe da SettingsBase, chiamandola ad esempio Globals:

Public Class Globals
  Inherits SettingsBase

  Public Documents() As String ' Un array di nomi di documenti
  Public WordWrap As Boolen ' True se occorre applicare il word wrapping

  ' ...

End Class

Tutte le variabili Public in questa classe possono essere salvate e ricaricate da file semplicemente usando i metodi Load e Save che la classe eredita da SettingsBase. Poichè un overload di questi metodi accetta uno Stream, è anche possibile salvare e ricaricare da altri medium, ad esempio un campo di database.

Usare questo approccio per implementare anche il salvataggio e il caricamento delle impostazioni di utente e di applicazioni è banale, e infatti ho anche definito delle classi UserSettingsBase e ApplicationSettingsBase. Ereditando da queste classi astratte è possibile creare insiemi di variabili distinte per ciascun utente oppure condivise da tutti gli utenti della applicazione. Come accade per la classe My.Settings, le variabili sono automaticamente caricate alla partenza della applicazione e salvate prima di uscire. A differenza di My.Settings, è possibile salvare le impostazioni su database centralizzati (cosa molto comoda per supportare applicazioni smart client con centinaia di utenti che possono fare il login da qualunque stazione della rete). Ma soprattutto, a differenza di My.Settings, queste classi sono utilizzabili anche in Visual Basic 2003 (e più in generale in .NET 1.1).

Il codice delle classi SettingsBase, UserSettingsBase e ApplicationSettingsBase non è proprio banale, quindi ho pensato di commentarlo a dovere e di scriverci un articolo di accompagnamento. Alla fine ne è venuto fuori un testo di oltre 30K, che non era quindi molto adatto a un post di blog, per cui ho deciso di pubblicarlo nella sezione articoli del sito, insieme al codice sorgente completo, al seguente link

Come probabilmente già sapete, sono disponibili sul sito Microsoft le prime specifiche delle future versioni di Visual Basic e di Visual C#. La chiave di quasi tutte le nuove feature è il progetto Linq, che oramai è ampiamente dibattuto in articoli, blog, sessioni alla PDC e persino video, come se dovesse essere rilasciato la prossima settimana. Per dirla davvero in due righe, Linq permetterà di integrare meglio i linguaggi tradizionali con linguaggi db-oriented tipo SQL, e offrirà una sintassi standard per eseguire query su collection di oggetti e tabelle di database in modo molto simile.

Quasi tutte le nuove feature del linguaggio, ad esempio gli anonymous types e la dichiarazione implicita delle variabili (che è necessaria per supportare gli anonymous types), sono una conseguenza indiretta dell'adozione di Linq. Quando scrivo una istruzione Linq come Dim result = Select Name,Population From Country In Countries Where Country.Population < 1000000, il valore restituito in result è una collection di tipi anonimi che "derivano" (ma non nel senso dell'editarietà) dalla classe Country ma hanno solo i campi Name e Population. In quanto anonimi, questi tipi non hanno evidentemente un nome e quindi non li posso usare nella clausola As per dichiarare la variabile result. L'adozione di Linq ha portato anche alla necessità di estendere le classi "al volo" mediante extension methods e a offrire un supporto più esteso al late binding. Anche l'introduzione delle dynamic interfaces va nella stessa direzione.

Forse perchè quest'anno (come l'anno scorso, del resto) NON sono andato alla PDC, ma non mi sento contagiato da questa grande euforia. Per una serie di motivi che proverò a sintetizzare. Prima di continuare, però un piccolo ringraziamento a Dino per un suo post che mi ha dato la voglia di scrivere questa paginetta.

Prima di tutto, dopo anni che ci hanno spiegato (e in cui noi "esperti" abbiamo tentato di spiegarlo ai programmatori/lettori) che occorre scrivere codice strong-typed, improvvisamente c'è questa virata verso i linguaggi dinamici. Quando era il VB a incoraggiare il late binding erano tutti a dargli addosso, urlando che era una vergogna che un linguaggio moderno supportasse queste sconcezze. Oggi improvvisamente la parola late binding non è più un tabù, e anzi persino il C# ne sarà contagiato. Ovviamente, il late binding di VB9 e C#3 è ben più robusto quello che si aveva in VB6 (e si puo' tuttora avere in VB.NET) usando variabili Variant e Object, ma è comunque vero che le chiamate agli estension method e alle dynamic interfaces saranno molto meno performanti del solito. Senza contare il fatto che le dichiarazione implicite dei tipi renderà il codice meno leggibile di quello che è ora. Considerando che molti programmatori VB non si sono ancora abituati a Option Explicit, non lo considero certo un progresso.

La seconda considerazione, anche più importante, è che in realtà non mi pare che l'introduzione di Linq (e delle feature accessorie che porta in dote) serva a risolvere una esigenza realmente sentita tra gli sviluppatori. Da anni si scrivono applicazioni super-complesse usando i linguaggi tipo SQL per manipolare i dati e i linguaggi "tradizionali" come VB e C# per tutto il resto. Il problema non è nella sintassi con cui si accede ai dati, lo è nel fatto che è difficile mappare un paradigma "a oggetti" basato su relazioni uno-a-uno e uno-a-molti (le collection) in memoria con una memorizzazione in un db relazionale. Sarebbe bello avere un unico linguaggio per entrambi i compiti, ma almeno con i database relazionali forse questa fusione è semplicemente impossibile. Non mi pare che Linq risolva questi problemi.

La dimostrazione indiretta che questa convivenza è molto difficile è data dal fallimento del progetto ObjectSpaces, sulle cui versioni alfa si sono sprecati fiumi di inchiostro e ore e ore di sessioni alla conferenze varie. Ricordo le mie discussioni con amici e colleghi alla PDC 2003, ero quasi l'unico ad avere riserve mentali su quella meravigliosa tecnologia del futuro, proprio per i motivi sopra detti. Si è visto come è andata a finire.

Per fortuna, insieme alle feature appena descritte, il VB è stato espanso anche per colmare le (pochissime) differenze esistenti con il C# 2.0, ad esempio il supporto nativo per i nullable type e il rilassamento dei delegate. Non aggiungeranno gli iterators, almeno al momento, e anche il supporto per i metodi anonimi non è sicuro. D'altra parte i tipi nullable in .NET 2.0 sono praticamente inutili e gli iterator servono a un programmatore su mille. I metodo anonimi - o meglio, le lamba functions come dovrebbero chiamati - sono decisamente più interessanti, ma sono anche una pericolosi, soprattutto quando li si usa per registrare "al volo" dei gestori di eventi che non possono mai essere de-registrati. In mano a programmatori meno che accorti saranno soprattutto in grado di fare proliferare i bug.

Insomma, mi sembra che i linguaggi più diffusi nel mondo Windows stiano andando in una direzione molto accademica e molto poco pratica. Io non sono un esperto di linguaggi di programmazione, ma mi scontro quasi quotidianamente contro qualche limite del linguaggio VB o C# (intendo i limiti che non si possono superare semplicemente scrivendo una libreria esterna). Ad es. manca la possibilità di compilare al volo e aggiungere metodi e proprietà a una classe (e non solo nuove classi, come si può fare mediante Reflection.Emit). Se fosse possibile implementare una interfaccia in una classe già esistente (e già compilata in una DLL), potrei rendere serializable, remotizzabile o disposable una classe che non lo è. Le partial class di VS2005 non aiutano in questo caso e dagli esempi che ho visto neanche le dynamic interfaces di VB9 e C#3 saranno in grado di farlo.

Un'altra feature che sarebbe utile è l'aggiunta al volo di attributi a una classe o a un suo membro, il che permetterebbe ad esempio di variare il livello transazionale di un ServicedComponent o di decidere esattamente quali membri serializzare. Mi piacerebbe anche che il mio linguaggio includesse un valutatore di espressioni che sappia interpretare una stringa contenente operatori, chiamate a metodi e soprattutto variabili definite nel programma. (Quello è un tipo di late-binding che accetterei volentieri.) Oppure un meccanismo built-in per intercettare tutte le chiamate ai membri di una classe già compilata, una specie di oggetto proxy universale. Visto che sto sognando ad occhi aperti, gradirei tanto anche un meccanismo che permetta di influire sul processo di JIT-compilation e qualche hint per l'ottimizzazione del codice. Anche i generics dovrebbero essere resi più potenti di quel che sono oggi. (Ho scritto a proposito di questi limiti in questo post e in questo post). E perchè non la possibilità di scrivere codice IL inline?

Per il momento niente di tutto questo. Accontentiamoci di Linq e aspettiamo la prossima PDC

Mentre sto rivedendo il capitolo sui generics, mi è tornato in mente un trucchetto semplice ma efficace per simulare i generics anche con .NET 1.x. Si tratta di sfruttare in modo poco ortodosso la capacità di definire degli alias per un tipo, mediante una direttiva Imports (VB) o using (C#). Ecco un esempio di quel che intendo, che implementa una collection di oggetti Widget (definiti da qualche parte nel namespace MyApplication):

' VB.NET
Imports ItemType = MyApplication.Widget

Public Class WidgetCollection
   Inherits CollectionBase

   Public Sub Add(ByVal item As ItemType)
      Me.List.Add(item)
   End Sub

   Public Sub Remove(ByVal item As ItemType)
      Me.List.Remove(item)
   End Sub

   Default Public Property Item(ByVal index As Integer) As ItemType
      Get
         Return CType(Me.List(index), ItemType)
      End Get
      Set(ByVal Value As ItemType)
         Me.List(index) = Value
      End Set
   End Property
End Class