Around and About .NET World

A distanza di quasi un mese dal rilascio della versione inglese, è stata resa disponibile anche la release italiana definitiva dei Silverlight Tools per Visual Studio 2008 SP1.

E' stata da poco rilasciata la nuova versione del Windows Home Server Toolkit, un insieme di strumenti per l'analisi e la risoluzione dei problemi che possono affliggere Windows Home Server. Questa release, la 1.1, è disponibile sia per i sistemi a 32-bit, sia per quelli a 64-bit (a differenza della versione 1.0, che era appannaggio esclusivo dei 32-bit).

Come ho scritto nel forum di DotNetToscana, in questi giorni ho avuto modo di fare qualche prova con due tra i più diffusi word processor javascript per il web: FCKeditor e TinyMCE. In particolare, ho approfondito l'utilizzo di quest'ultimo, che mi sembra davvero ben fatto e facile da utilizzare. E' open-source, rilasciato con licenza LGPL e compatibile con la maggior parte dei browser attuali (Mozilla, Internet Explorer, Firefox, Opera, Safari e Google Chrome).

Sul sito Internet del produttore è anche disponibile la versione preliminare di un controllo per facilitare l'integrazione dell'editor in applicazioni ASP .NET, ma si tratta comunque di un'operazione molto semplice, poiché richiede essenzialmente di aggiungere un paio di script Java alla pagina in cui lo si vuole visualizzare. Per .NET, inoltre, è disponibile un particolare modulo, chiamato Compressor, che permette di velocizzare il caricamento del word processor, comprimendo in formato ZIP gli script prima di inviarli al client. Nei prossimi giorni continuerò ad usarlo, ma per adesso sono pienamente soddisfatto di esso.

Per impostazione predefinita, nei Web Application Projects l'opzione Edit and Continue è disattivata. Non so se questa cosa è dovuta a motivi particolari, ma per fortuna attivarla è semplicissimo: basta porre il segno di spunta ad un paio di checkbox, come indicato in questo post.

Dopo aver letto il mio post sui problemi con l'oggetto GZipStream, l'amico Matteo Baglini mi ha consigliato di provare la libreria DotNetZip, disponibile su CodePlex. Incuriosito, l'ho scaricata ed ho subito provato ad usarla per comprimere il mio solito file PDF da 4,48 MB (anche di esso ho parlato nello scorso post). Risultato: anche con DotNetZip ho ottenuto uno ZIP di 4,44 MB; in pratica ho raggiunto lo stesso livello di compressione ottenibile con la classe GZipStream. Forse sarò io che ho utilizzato un file PDF "problematico", ma per il momento continuo ad usare SharpZipLib, che occupa pure meno di DotNetZip .

Il .NET Framework, a partire dalla versione 2.0, fornisce il namespace System.IO.Compression, al cui interno troviamo, tra le altre, la classe GZipStream, con cui è possibile comprimere e decomprimere file in formato ZIP. Facendo qualche prova, tuttavia, ho notato che essa non garantisce un elevato livello di compressione, per usare un eufemismo... Il dubbio mi è venuto quando ho compresso un file PDF di 4,48 MB, ottenendo uno ZIP di 4,44 MB; mi sembrava un po' strano, quindi ho provato ad utilizzare WinRAR, che ha prodotto un archivio di appena 1,46 MB. Allora ho scaricato SharpZipLib: comprimendo lo stesso file con questa libreria, ho in effetti ottenuto un file di 1,46 MB. Per avere un riferimento, queste sono le due routine che ho utilizzato:

private static void CompressWithNET(string sourceFileName, 
                                       string destinationFileName)
{
    using (FileStream fs = new FileStream(destinationFileName,
                                                  FileMode.Create))
    {
        FileStream source = File.OpenRead(sourceFileName);
        byte[] buffer = new byte[source.Length];
        source.Read(buffer, 0, buffer.Length);
        source.Close();

        //Crea lo stream compresso.
        GZipStream zip = new GZipStream(fs, CompressionMode.Compress, false);
        //Comprime i dati.
        zip.Write(buffer, 0, buffer.Length);
        //Chiude lo stream.
        zip.Close();
    }
}

public static void CompressWithSharpZipLib(string sourceFileName, 
                                        string compressedFileName)
{
    //Comprime il file specificato.
    using (ZipOutputStream zipStream = new ZipOutputStream(
                                  File.Create(compressedFileName)))
    {
        FileStream fs = File.OpenRead(sourceFileName);
        byte[] buffer = new byte[fs.Length];
        fs.Read(buffer, 0, buffer.Length);

        //Crea una nuova entry nel file ZIP.
        ZipEntry entry = new ZipEntry(Path.GetFileName(sourceFileName));
        entry.DateTime = File.GetLastWriteTime(sourceFileName);
        entry.Size = fs.Length;
        fs.Close();

        Crc32 Crc = new Crc32();
        Crc.Update(buffer);
        entry.Crc = Crc.Value;

        zipStream.PutNextEntry(entry);
        zipStream.Write(buffer, 0, buffer.Length);

        //La compressione è terminata.
        zipStream.Finish();
    }
}

Da una rapida ricerca su Internet, sembra che il problema dello GZipStream abbia a che fare con la gestione interna del buffer utilizzato per mantenere i dati della compressione. Indagherò, ma nel frattempo continuerò ad utilizzare SharpZipLib.

A questo indirizzo è disponibile una grande quantità di link a materiale dedicato a Visual Studio 2010. Da non perdere!

A questo indirizzo è disponibile una breve spiegazione di come usare le stored procedure con l'Entity Framework di .NET 3.5 SP1.

Poco fa, collegandomi al mio account di Gmail, ho notato  che è stata aggiunta una nuova funzionalità: il supporto ai temi, ovvero un insieme di layout predefiniti che permettono di cambiare l'aspetto della webmail, modificandone i colori e, in alcuni casi, anche aggiungendo immagini di sfondo. Personalmente, ormai sono abituato alla vecchia impostazione, che mi sembra semplice e funzionale, ma, come si dice, de gustibus non disputandum est...

Ieri ho portato una testimonianza di come l'utilizzo dello StringBuilder di .NET mi abbia consentito di migliorare sensibilmente le prestazioni di un algoritmo. Oggi la mia opera di ottimizzazione è proseguita, ed è toccato ad una routine Javascript, che creava una tabella HTML concatenando stringhe con, ahimé, l'operatore +. In questo caso la modifica dell'algoritmo è stata un filino più lunga, perché Javascript non include un oggetto analogo allo StringBuilder (o StringBuffer, secondo la terminologia Java). Ma è bastata una ricerca su CodeProject per trovare questo progetto, che fornisce uno StringBuilder per Javascript semplicissimo da usare e davvero efficiente.

Le stringhe in .NET sono oggetti immutabili, quindi se si devono concatenare insieme un numero elevato si stringhe, usare l'operatore + è inefficiente, perché ogni volta verrebbe creata in memoria una nuova stringa. Per ovviare al problema, si deve utilizzare l'oggetto StringBuilder che, come si legge su MSDN, rappresenta una sequenza mutabile di caratteri, quindi ad esso è possibile aggiungere, rimuovere, inserire o sostituire caratteri senza la necessità di istanziare un nuovo oggetto in memoria.

Questa è la favoletta che tutti noi conosciamo... Però quando oggi, facendo debug di codice scritto da altri, ho sostituito tutte le concatenazioni di stringhe con uno StringBuilder ed ho osservato che il tempo di esecuzione è passato da 2 minuti a 3 secondi scarsi, mi si sono illuminati gli occhi

Come tutti sappiamo, utilizzando la proprietà IsPostBack è possibile determinare se una pagina ASP .NET è stata caricata per la prima volta oppure in seguito ad un PostBack (causato, tipicamente, dalla pressione di un pulsante). Ma se si ha la necessità di sapere quando una pagina è ricaricata con il tasto Aggiorna del browser? In questo caso non esiste una proprietà "pronta all'uso", ma cercando sulla rete si possono trovare diverse soluzioni, le più efficienti delle quali si basano sull'utilizzo di un opportuno HttpModule. A questo indirizzo è disponibile una esauriente descrizione del problema, accompagnata da un file ZIP che contiene il modulo HTTP già compilato.

L'oggetto CultureInfo di .NET è utilizzato per indicare una cultura, che può essere composta da due parti: una cultura neutrale e una specifica. Ad esempio, nella cultura en-US, en rappresenta la cultura neutrale, mentre US è la cultura specifica. Quando si ha un oggetto di tipo CultureInfo, è possibile recuperare la cultura neutrale semplicemente accedendo alla sua proprietà TwoLetterISOLanguageName, mentre per la cultura specifica si deve ricorrere alla classe RegionInfo:

RegionInfo ri = new RegionInfo("en-US");
string specificCulture = ri.TwoLetterISORegionName;

Ovviamente lo stesso risultato si può ottenere anche manipolando la stringa en-US, ma questa soluzione garantisce che, se le regole di codifica delle culture in futuro saranno modificate, un aggiornamento del runtime del Framework .NET è tutto quello che serve perché la nostre applicazioni continuino a funzionare.

La notizia non è proprio di primo pelo, ma a causa degli impegni lavorativi dell'ultimo periodo, mi era passata inosservata... A quanto pare, da qualche tempo Windows Server 2008 R2 è entrato in fase di Beta testing. A questo indirizzo sono disponibili maggiori informazioni sulle novità introdotte.

Una delle novità maggiormente decantate di .NET 3.5 è l'inferenza dei tipi, ovvero la possibilità di determinare staticamente, a tempo di compilazione, il tipo di una variabile in base al suo contenuto. Tutto quello che serve, per utilizzarla, è indicare var come tipo di dato: quando incontra questa parola chiave, il compilatore sa che deve analizzare i dati memorizzati nella variabile per determinarne il tipo. Si tratta di una funzionalità molto comoda e che, quando si utilizza LINQ, spesso permette di evitare la creazione di classi specializzate per contenere i risultati delle interrogazioni, consentendo comunque di avere un accesso tipizzato alle informazioni.

Bisogna comunque stare attenti quando si utilizza la parola chiave var. In alcuni casi, infatti, si potrebbero ottenere risultati diversi da quelli che ci si aspettano. Consideriamo il seguente esempio:

short s = 4;
var i = s + 1;
Console.WriteLine("Il tipo della variabile i è: " + i.GetType().ToString());

Poiché la variabile s è di tipo short (System.Int16), si potrebbe pensare che il risultato di s + 1 (ovvero 5) sia anch'esso di questo tipo... In realtà non è così: poiché, per impostazione predefinita, l'operatore + applicato a due dati numerici interi restituisce un int, la variabile i sarà di quest'ultimo tipo (d'altra parte, se al posto di var i =... si fosse usato short i =..., si sarebbe ottenuto un errore di compilazione).

Attenzione, quindi: quando si utilizza l'inferenza di tipi, è bene verificare che tutto funzioni come previsto.