Maurizio's blog 3.0

Segnalo un gran bel Visualizer per Visual Studio 2005/2008. Trattasi di Mole v.4.2, un visualizer in grado di funzionare con diversi oggetti di diverse tipologie di progetto, che comprendono WinForms, WPF, WCF, WF, ASP.NET, XBAP. Io lo trovo molto utile soprattutto per progetti WCF, WPF, dove gli oggetti con cui si ha a che fare sono abbastanza complessi e strutturati. Uno strumento del genere, molto ben fatto e performante, può far risparmiare diversi “mal di testa” quando si effettua il debugging di progetti di questo tipo.

Download

Negli ultimi tempi mi è capitato spesso di lavorare su applicazioni che utilizzano Oracle come database piuttosto che Sql Server e, naturalmente, ho dovuto utilizzare nello strato di accesso ai dati le classi specifiche di Oracle, meglio note come Oracle Data Provider for .NET. Utilizzare queste classi significa avere a che fare con oggetti tipici di Oracle, es. gli Oracle data type, o i cursori utilizzati per contenere i resultset derivanti da una chiamata ad una store procedure, ecc.

Non avendo una esperienza significativa in Oracle ho sempre pensato che il supporto per .NET fosse alquanto limitato e ridotto all’essenziale,  es.  aprire una connessione ed eseguire un comando SQL che ritorna un resultset.  Ma noto con piacere che mi sbagliavo. La versione 11.1.0.6.20 dell’ODP for .NET fornisce sia una integrazione con l’ambiente Visual Studio  in versione 2005/2008, es. Server Explorer, wizards e designer, sia una integrazione con la piattaforma ASP .NET. Quest’ultima per me è la più interessante in quanto è possibile utilizzare alcuni providers  (argomento di cui ho già parlato in un mio articolo apparso sul sito dello user group DotNetSide) ed utilizzare come repository un database Oracle. Nello specifico i providers sono i seguenti:

• Memberhip (gestione degli utenti e validazione)
• Role (ruoli)
• SiteMap (mappa del sito)
• SessionState (  la Sessione di una applicazione ASP .NET )
• Profile (profili degli utenti)
• Web Event (informazioni circa lo “stato di salute” delle applicazione ASP .NET)
• Web Part personalization (chi lavora con le WebParts può ora memorizzare le informazioni di personalizzazione in un db Oracle)
• Cache Dependency

Il supporto per il Cache Dependency Provider a mio avviso è il più interessante di tutti. Ho già avuto modo di utilizzare ed apprezzare questo meccanismo (invalidazione automatica di un oggetto in cache a fronte di modifiche apportate a resultset memorizzati in un database mediante il meccanismo di notifica) su applicazioni basate su database SqlServer. Sarà sicuramente interessante e produttivo poterlo utilizzare anche in quei contesti dove il database è Oracle.

Questa informazione me la annoto perchè sicuramente utile. Avevo già parlato precedentemente delle sottili e a volte subdole differenze esistenti tra il linguaggio VB .NET  e C#, differenze che possono anche riguardare il comportamento di Visual Studio, quindi non strettamente legate a costrutti di programmazione o alla semplice sintassi.

Questa differenza però mi sorprende parecchio e non riesco a comprenderne a fondo il motivo. Presto detto: se si utilizza l’incremento automatico nel numero di versione in un assembly (per intenderci quando impostiamo questa riga

[assembly: AssemblyVersion("1.0.*")]

nel file AssemblyInfo, otteniamo un risultato differente a seconda se l’assembly è scritto in VB .NET o in C#. Se è scritto in VB .NET l’incremento automatico è operato solo alla prima build, mentre alle successive build sulla stessa istanza di Visual Studio il numero di versione resta invariato (se l’assembly viene ricompilato in una differente istanza di Visual Studio il numero di versione è incrementato).

Se, viceversa, l’assembly è scritto in C#, ogni build produce un incremento automatico del numero di versione. Appena mi è possibile proverò questa funzionalità, anche se la documentazione MSDN è abbastanza chiara.

Questo comportamento differente in funzione del linguaggio avrà anche una sua logica, ma non è sicuramente immediatamente chiara.

Inoltre, non condivido la motivazione che la documentazione MSDN produce per spiegare il tutto: poichè il numero di versione è inserito solo a titolo informativo in un assembly non firmato con uno strong name, il problema non si pone. Viceversa, se l’assembly deve essere dotato di strong name, viene sconsigliato l’uso dell’incremento automatico, in VB .NET chiaramente, perchè in C# non c’è alcuna controindicazione.

Questo shortcut è davvero utilissimo: CTRL+K+F premuto all’interno di Visual Studio con attiva una finestra di editor del codice sorgente. Selezionando una regione di codice non formattato, non allineato o non indentato correttamente (tipicamente derivante da un precedente copia e incolla), questa combinazione allinea perfettamente le righe di codice in un colpo solo !

Fonte: Mark Schmidt’s Abode

P.S: Nel commento al post linkato, leggo che la combinazione CTRL+K+D effettua la stessa formattazione delle righe ma agendo sull’intero file e non solo sulla selezione di testo. Spettacolo!

Ho provato SourceMonitor, un interessante tool freeware per effettuare metriche sul codice sorgente scritto in vari linguaggi di programmazione, tra cui C#, C, C++, VB .NET, Delphi.

Attraverso una interfaccia di gestione molto semplice acquisisce una serie di informazioni, le metriche appunto, analizzando il codice sorgente di un progetto. Queste informazioni possono essere salvate in diversi momenti e nominate (checkpoints), onde poter mettere a confronto metriche di uno stesso progetto create in momenti diversi.

Analizzare le metriche del proprio codice aiuta ad evidenziare eventuali colli di bottiglia, ovvero parti dello stesso da sottoporre a code review, e a migliorare quindi la qualità del codice scritto.

Ecco un elenco delle metriche a mio avviso più importanti:

-% delle linee di codice commentate rispetto al totale delle linee di codice presenti in un file;
-Numero delle classi, interfacce o strutture definite in un file;
-Numero medio di metodi per classe, interfaccia o struttura;
-Valore di complessità per tutti i metodi, ovvero numero totale dei diversi percorsi di esecuzione che ogni metodo  possiede (maggiore è questo valore, più “complesso” è il metodo). Questo valore si puo’ ottenere sia per singolo  metodo, sia come media della complessità di tutti i metodi presenti.

Come detto, analizzare le metriche del codice può aiutare a scrivere codice di qualità, e quindi ad essere uno sviluppatore migliore.

Sviluppare una applicazione managed scegliendo un linguaggio piuttosto che un altro non è solo un fatto di preferenza, di predilezione o di semplice sintassi. E’ di più. Scegliere VB .NET o C#, ad esempio, significa accettare differenze che vanno al di là della preferenze personali, ma che coinvolgono anche alcune feature dell’ambiente di sviluppo. Un esempio ? In un progetto Windows Form scritto in VB .NET, l’ambiente Visual Studio visualizza il codice della form generato dal designer (la partial class per intenderci) solo se si seleziona la vista “mostra tutti i files” Nello stesso progetto scritto però in C# la stessa vista è abilitata di default. Una differenza sottile ma significativa che non ha nulla a che vedere con il linguaggio

Reso disponibile da Microsoft un interessante set di estensioni per Visual Studio 2005, inizialmente presenti solo nell’SDK, sicuramente utili a rendere più agevole la vita dello sviluppatore. Sto parlando di Microsoft Visual Studio 2005 IDE Enhancements, disponibile per il download da qualche giorno, che comprende: a) una serie di snippet code per il linguaggio C++; b) Indexer Find, un tool basato su Index Service per migliorare le ricerche nell’IDE;  c) Super Diff Utility, utility per confrontare il contenuto di 2 files evidenziando le differenze (stile Visual Source Safe); d) Event Toaster Utility, per aggiungere eventi di notifica legati all’IDE, es. notifica nella tray area dopo ogni build eseguita con successo (molto carina); e) Source Code Outliner, un tool che visualizza una lista ad albero dei tipi e relativi membri. Tutto troppo bello ed utile, se non fosse che: a) il Source Code Outliner si blocca indefinitivamente nel tentativo di aggiornare il proprio contenuto; b) l’IDE si blocca imprevedibilemente (ho l’impressione che l’Indexer Find blocchi la CPU per troppo tempo nel tentativo di aggiornare l’indice delle ricerche; c) non è possibile abilitare/disabilitare selettivamente ogni estensione, quindi o tutto o niente. Morale della favola: ho dovuto disinstallare il tutto con la stessa velocità con cui lo avevo installato, a causa dei blocchi frequenti dell’IDE e del Source Code Outliner. Mi piacerebbe conoscere l’eventuale esperienza di altri sviluppatori sull’argomento. I commenti sono aperti e graditi.

Aggiungendo una semplice reference binaria ad un progetto in VS 2005 (es. un Web Site Project), vale a dire selezionando direttamente una class library (file *.dll) da Add Reference\Browse, viene automaticamente creato nella directory bin del progetto un file con lo stesso nome del componente (la dll) e l’estensione refresh, es. mydll.refresh se aggiungo la reference mydll.dll. Questo è un semplice file di testo; infatti aprendolo con Notepad è possibile leggerne il contenuto, ovvero il path relativo in cui è contenuta la dll che abbiamo referenziato. A cosa serve esattamente questo file ? Serve a tener aggiornata la bin del progetto con l’ultima versione della dll disponibile al path indicato. Infatti, ad ogni compilazione VS verifica che al percorso indicato nel file refresh non sia disponibile una versione più aggiornata della dll, e, in caso affermativo, la copia nella directory bin del progetto, sollevando lo sviluppatore dall’onere di copiare manualmente la dll referenziata E’ possibile che più progetti nella stessa solution referenzino la stessa dll (ad es. una dll condivisa della ns. applicazione). In questo caso, è necessario assicurarsi che la dll referenziata dai vari progetti (la dll shared) abbia lo stesso numero di versione in tutti i punti in cui è referenziata. In caso negativo, VS “perderà tempo” durante la compilazione assumendo che della stessa dll sia disponibile una versione più aggiornata, provocando un notevole rallentamento della compilazione; per intenderci, può trascorrere anche qualche minuto prima che i risultati della compilazione inizino ad apparire nella finestra Output. Per maggior approfondimento è utile questo dettagliatissimo post di ScottGu

La start page di Visual Studio 2005 presenta la lista dei recents projects, contenente progetti e soluzioni aperti di recente. Questa lista può diventare presto inutile per coloro che aprono/creano un progetto/soluzione “una tantum” solo per motivi di test, e magari dopo aver verificato il funzionamento il progetto viene addirittura cancellato dal disco.  Infatti la lista non è modificabile in alcun modo tramite GUI, ma da registry sì.

Posizionandosi su questa chiave

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\ProjectMRUList è possibile cancellare le voci non più valide e “ripulire” quindi la lista dei recents projects.

Ai tempi in cui utilizzavo Visual Studio 6.0 (tanto tempo fa, ma anche adesso, ogni tanto…:)),  una delle funzionalità dell’IDE che più mi tornava utile era la possibilità di compilare ed eseguire porzioni di codice senza doverli necessariamente salvare sul disco in progetti e soluzioni (allora si parlava di progetto e gruppi di progetto). In Visual Studio 2002/2003 questa funzionalità è assente, con la conseguenza di veder proliferare sul proprio hard disk progetti e soluzioni che non hanno alcuna utilità ma sono solo il risultato di prove di qualche “snippet code”. A dir la verità ho anche utilizzato un tool freeware chiamato Snippet Compiler, molto valido, che, come dice il suo stesso nome, è in grado di compilare ed eseguire al volo snippet code ed opzionalmente salvarli su disco, con tanto di presenza dell’intellisense, anche se a mio avviso non impeccabile. In Visual Studio 2005 questa funzionalità è riapparsa sotto il nome di “Zero Impact Projects” (ZIPs). Infatti, posizionandosi in Tools\Options\Project and Solutions\General, è accessibile il check “Save new projects when created” il cui valore di default è “checked”. Disattivandolo, ogni nuovo progetto creato non sarà più salvato su disco se non su esplicita richiesta, permettendo il test “al volo” di un blocco di codice. Tuttavia, creando uno Zero Impacts Projects viene creata comunque una directory con lo stesso nome del progetto sotto il path “Visual Studio 2005” presente nella directory del profilo utente correntemente loggato. Questa directory, anche se vuota, resta presente su disco anche se si opta per non salvare i files del progetto, creando, di fatto, cartelle indesiderate anche se con un impatto molto minore rispetto a Visual Studio 2002/2003.

I visualizers sono una utilissima feature del debugger Visual Studio .NET 2005. Questi componenti agiscono in fase di debug di una applicazione per visualizzare una interfaccia utente creata ad hoc contenente i valori di variabili o di interi oggetti. Un visualizer riflette il particolare tipo di oggetto in fase di debug e visualizza le sue informazioni con l’interfaccia utente appropriata rispetto all’oggetto.

Ad es., il visualizer per il Dataset, già previsto in Visual Studio insieme a quelli per testo, xml e html, visualizza le informazioni di ogni singola tabella in esso contenuta attraverso una visione tabellare delle informazioni.

Un visualizer può funzionare in entrambe le direzioni, vale a dire che l’interfaccia grafica può sia visualizzare le informazioni che modificarle, reinviandole al debugger

Si possono creare custom visualizer ed utilizzarli in fase di debugging. Questo utilissimo visualizer, segnalato anche da MSDN Magazine come uno dei 10 tools che ogni sviluppatore dovrebbe avere installato, permette di visualizzare le informazioni sugli oggetti inseriti nella cache di ASP .NET, comprendenti scadenza, dipendenze da file, da chiave o da tabella.