Mole, visualizer integrato per visual studio

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

Impossibile aggiungere una service reference in visual studio 2008

Questo workaround spero sia utile a chi si è trovato nella stessa mia situazione, e cioè che improvvisamente Visual Studio 2008 si rifiuta di aggiungere una Service Reference ad un servizio WCF, dando questo errore:

The components required to enumerate web references are not installed on this computer. Please re-install Visual studio.

Ho poi scoperto che il problema si presentava anche aggiungendo semplici web reference (ASP .NET web services) a progetti creati con Visual Studio 2005.

Per risolvere il problema non è mica necessario reinstallare Visual Studio 🙂

Basta lanciare l’ambiente di sviluppo da prompt dei comandi (quello di Visual Studio) con il parametro /resetskippkgs, quindi in questo modo:

devenv /resetskippkgs

Il parametro /resetskippkgs impedisce che siano caricati eventuali VSPackages aggiuntivi, che potrebbero creare problemi con lo startup dei componenti di Visual Studio. Era proprio quello che accadeva a me. Chiaramente basta lanciare solo una volta Visual Studio in quel modo, giusto per disabilitare il caricamento dei VSPackages.

Le direttive using devono essere poste all’interno del namespace

Questo post inizia con una frase tratta da un post di Scott Hanselmann con cui mi trovo completamente d’accordo:

Don’t believe everything you read, even on a Microsoft Blog.             

Don’t believe this blog, either!

Decide  for yourself with experiments if you need a tiebreaker!

Credo sia proprio vero, mai fidarsi ciecamente di quello che si legge in giro, soprattutto quando seri dubbi farebbero pensare il contrario.

Il motivo è presto detto: utilizzo normalmente FxCop come strumento di analisi del codice sorgente, lo trovo molto completo e ben fatto. Spinto dalla curiosità ho voluto utilizzare Source Analysis, un tool gratuito fornito da Microsoft ed integrato nell’IDE di Visual Studio. Dopo la primissima prova fatta mi ha incuriosito una sua segnalazione:

SA1200 – All using directives must be placed inside of the namaspace.

Per farla breve, tutti i files sorgenti del mio progetto provocavano una segnalazione di questo tipo poichè le direttive using erano poste esternamente alla definizione del namespace, così come automaticamente viene creato uno scheletro di una classe all’interno dell’IDE. La segnalazione in questione invita invece ad includere le direttive using all’interno della definizione del namespace, semprecchè sia presente. Facendo qualche ricerca in giro ho scoperto che in questo modo il compilatore segnala immediatamente una eventuale ambiguità tra i nomi dei tipi creati all’interno del proprio namespace e i tipi presenti nei vari namespace del .NET Framework. E fin qui nulla di strano.

Ho scoperto inoltre che questa guideline servirebbe anche ad aumentare le prestazioni, almeno nei casi specifici, in quanto forzarebbe il “lazy loading” degli assembly e non il caricamento immediato. In altre parole, quando il viene invocato un metodo di una classe e viene compilato il codice “just in time” (JITTED) il lazy loading permette di caricare in memoria solo gli assembly referenziati che servono all’invocazione del metodo stesso, e non tutti gli assembly referenziati da una classe, a prescindere se utilizzati o no da una specifica invocazione di un metodo. Questo permette di caricare solo lo stretto necessario anche se una classe referenzia un assemby non utilizzato da un metodo.

Sinceramente non mi è venuto in mente un solo valido motivo per cui una direttiva using posta in un certo modo potesse influenzare l’attività del CRL a runtime, e sono rimasto alquanto dubbioso sulla effettiva validità. Prima che potessi avere il tempo di fare una prova specifica mi son trovato questo post di Scott Hanselmann, al quale rimando per una esauriente spiegazione, che dimostra come purtroppo ciò non sia affatto vero, cioè gli assembly referenziati vengono caricati tutti i memoria immediatamente, a prescindere se il metodo in questione li usa oppure no, ed a prescindere se le direttive using vengono poste all’interno o all’esterno della definizione di namespace.

Quindi la morale è: non credere mai a quello che leggi, neanche se lo leggi da questo blog :), ma sperimenta sempre.

Visual source safe – troubleshooting

Nel mio lavoro quotidiano come consulente uso spesso e volentieri Visual Source Safe (sigh!)  come repository del codice sorgente. Come chi già lo usa sicuramente ben sa, Source Safe è un prodotto ormai datato che si porta dietro un pò di problemi di varia natura. Quindi, non è sempre facile “addomesticarlo” per ottenere quello che si vuole. Appunto un paio di workaround su come evitare certe situazioni che possono portare a problemi:

  1. Se si usa una cartella diversa da c:\inetpub\wwwroot per salvare i propri progetti web, non usare mai il comando File|Open fron Source Control. Questo comando, a dispetto della working folder impostata, salverà sempre il progetto web in una sottodirectory della directory c:\inetpub\wwwroot, con il risultato di avere una doppia copia del progetto web sulla propria macchina se si è scelto di utilizzare una directory differente per il proprio progetto. Questo comportamento si può evitare impostando la virtual directory della propria applicazione (che dovrà puntare alla directory fisica prescelta) PRIMA di eseguire il comando “Open from Source Control”.
  2. Source Safe NON è transazionale, quindi un crash del sistema nel bel mezzo di una operaizione di scrittura porta quasi sempre a corruzione del database, non sempre risolvibili attraverso l’utility “Analyze
  3. L’esecuzione del comando “Analyze” come pure di altri comandi di diagnostica non và a buon fine se risultano utenti ancora connessi al database; questo è anche logico, se non fosse per il fatto che non esiste un metodo “pulito” per disconnettere utenti che risultano ancora connessi. Per far questo occorre utilizzare alcuni strumenti del sistema operativo per disconnettere forzatamente un utente dalla rete.
  4. Effettuare un backup dell’intero database quanto più frequentemente possibile

Automatic properties in c# 3.0

Utilizzando C# 3.0 è possibile scrivere le proprietà di una classe in modo estremamente compatto, in questo modo:

Public string Nome {get; set;}

Questa modalità, chiamata “Automatic properties” permette quindi di omettere il riferimento al membro privato che normalmente viene “wrappato” dalla proprietà stessa.

Sarà compito del compilatore autogenerare al volo il membro privato al momento della compilazione. Questa caratteristica impone che il codice della classe non può in nessun modo accedere alla variabile privata, appunto perchè al momento della stesura del codice essa non esiste ancora in quanto sarà autogenerata in fase di compilazione. E’ quindi necessario utilizzare direttamente il nome della proprietà nel codice della classe per accedere al suo contenuto e/o modificarlo.

L’impossibilità del codice ad accedere alla variabile privata è dovuta al fatto che, poichè è possibile in qualsiasi momento tornare alla dichiarazione classica della proprietà indicando esplicitamente una variabile privata, è necessario assicurare al codice la piena compatibilità tra le due modalità. In altre parole, se si trasforma una “Automatic property” in una proprietà diciamo così “classica”, il codice che la utilizza continuerà a funzionare senza problemi perchè è certo che non avrà in nessun modo potuto utilizzare la variabile privata autogenerata. Per lo stesso motivo, non è possibile indicare un solo “accessor” per la proprietà ma dovranno essere indicati obbligatoriamente entrambi (get; set;), fermo restando che è sempre possibile indicare un ambito di visibilità diverso tra i due “accessor” (es. get; con visibilità public e set; con visibilità private)