Maurizio's blog 3.0

Avevo già parlato qui (post immediatamente sotto :-)) di uno strano crash di Visual Studio 2008 SP1, a seguito dell’esecuzione comando “Choose items” della toolbox.

Il problema sembrava essere dovuto alla presenza dei PowerCommands e di una loro presunta incompatibilità con il Service Pack 1. Infatti per poter tornare alla “normalità” era necessario un’azione estrema, ovvero rimuovere i PowerCommands, ed a quel punto il problema spariva.

Oggi scopro che attraverso un assemply redirection nel file di configurazione di Visual Studio (devenv.exe.config) il problema si risolve definitivamente, e che il crash si verificava anche nell’editor XAML. Maggiori info qui.

Quindi la soluzione è inserire questo frammento XML nel file di configurazione di Visual Studio:

Qualche giorno fa mi sono imbattuto in uno strano crash di Visual Studio 2008, dopo aver installato il Service Pack 1, vale a dire che il comando “Choose items” della toolbox era capace di mandare in crash l’intero IDE, scrivendo un laconico messaggio nell’Event viewer, del tipo

NET Runtime version 2.0.50727.3053 – Fatal Execution Engine Error (7A035E00) (80131506)

di nessuna utilità per la risoluzione del problema,  senza possibilità di scampo quindi. Dopo aver cercato invano per la rete per evitare di perdere ulteriore tempo ho evitato di disporre del controllo che mi interessava nella toolbox (precisamente una PropertyGrid) e l’ho inserito direttamente nel markup XAML della mia applicazione (una XBAP application).

Oggi ho letto questo post di Nazareno e speravo veramente di risolvere il problema, anche perchè questa volta la toolbox era indispensabile poichè dovevo inserire una intera suite di controlli.

Purtroppo non c’è stato niente da fare. Il problema sparisce solo dopo aver disinstallato i Power Commands, senza più reinstallarli.  Ma sono abituato ai Power Commands  e li trovo veramente utili.

Vale a dire che li disintallerò solo per utilizzare la toolbox, e poi li reinstallerò di nuovo…:-)

Il prossimo 13 settembre parteciperò ad una conferenza internazionale, precisamente la SQLBits, dedicata ai professionisti di Sql Server, in quel di Londra.

Se qualche sqlellaro vuole accodarsi non ha che da contattarmi.

Come chi programma in WPF ben sa, una applicazione WPF browser, meglio nota come XBAP application, gira all’interno del browser in un ambiente partial trust, oppure in una sandbox di sicurezza, come meglio si preferisce, per evitare appunto che il codice di una tale applicazione possa accedere a informazioni confidenziali oppure effettuare azioni non autorizzate. In particolari scenari, tuttavia, ad esempio in applicazioni Intranet, può nascere l’esigenza di dotare tali applicazioni di un maggior numero di permessi, oppure addirittura farle girare in ambiente full trust.

Bene, visto che per default una XBAP application viene eseguita in modalità partial trust, quali sono i passaggi necessari per farla funzionare invece in un ambiente full trust ?. Questo è il motivo di questo post. Di seguito elenco i passaggi che ho dovuto effettuare per raggiungere tale obiettivo, anche se alcuni sono un pò contorti e mi fanno dubitare di aver intrapreso la strada migliore, ma alla fine comunque il tutto ha funzionato:

• Occorre far si che il processo che ospita la XBAP application non venga eseguito con un process token povero di privilegi. Per far questo è necessario intervenire sul Registry (non sono però certo che non esistano metodi più comodi).  Occorre posizionarsi sulla chiave:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Windows Presentation Foundation\Hosting

e creare un valore DWORD denominato RunUnrestricted ed assegnargli il valore 1.

• Nella scheda Security, accessibile dalle proprietà del progetto, occorre scegliere come zona il valore “Custom” al posto di “Internet”. Lasciare il valore di default “This is a partial trust application” e non spuntare “This is a full trust application” come invece la logica vorrebbe. Se si sceglie “full trust” senza cambiare la zona (lasciando il valore di default) il meccanismo non funzionerà. Dopo aver fatto questa modifica, riaprendo la scheda Security, si noterà come sia spuntato il valore “full trust” e la zona sia impostata a “Custom” e non modificabile.

• Nel file app.manifest dell’applicazione occorre aggiungere l’attributo Unrestricted=”true”

• Se si vuol lanciare la propria applicazione mediante un url http, occorre firmare il manifest con un certificato digitale X.509. Quando creiamo la nostra applicazione XBAP Visual Studio genera un file con estensione “pfx”. Questo file rappresenta un certificato digitale temporaneo da usare a scopo di test. Occorrerà solo registrare tale certificato in Internet Exporer, scegliendo da menù Tools l’opzione “Options“, la scheda “Content” ed il pulsante “Certificates“. A questo punto click sul pulsante “Import” e partirà il wizard di importazione del certificato, dove attraverso vari passaggi il certificato di test sarà registrato (occorre scegliere come store  “Trusted root Certification Authorities“). E’ comunque possibile generare un certificato di test direttamente da Visual Studio, scegliendo la scheda “Signing” dalle proprietà del progetto e successivamente cliccando il pulsante “Create Test Certificate“. A questo punto partirà un wizard che permetterà la creazione e la esportazione del certificato in un file “pfx“, onde consentire la successiva importazione in Internet Explorer.

A questo punto eseguendo l’applicazione via web essa funzionerà con tutti i permessi assegnati (full trust).

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

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.

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.

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

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)

Vi è mai capitato che nella console di amministrazione di IIS per una certa web application sparisse il tab ASP .NET senza apparente motivo ?

A me sì, con tutte le conseguenze del caso, e senza che riuscissi a trovare una soluzione nei forum e user group. Ora finalmente la soluzione esiste.

E’ spiegata in modo dettagliato in questo post, ed inoltre, come afferma l’autore del post, non esiste nessuna soluzione immediata che pone riparo a questa anomalia. 

Da un po’ di tempo non sto frequentando più assiduamente gli eventi delle varie community in generale. Ho sempre considerato questi eventi di grande importanza per ciò che riescono a trasmetterti e per restare “a galla” nel campo informatico. Ora inizio a sentirne la mancanza, e per questo motivo mi sono iscritto ai Community Days 2008, evento imperdibile organizzato da Aspitalia, Guisa e Ugidotnet, che si terrà a Milano i prossimo 9 e 10 luglio. Quindi, io ci sarò, e se qualcuno ha voglia di scambiare 4 chiacchere “tecnologiche” non esiti a contattarmi. Ci si vede là !

Una delle più interessanti feature disponibili con la versione 3.5 del .NET Framework sono, a mio avviso, gli Extention Methods, caratteristica legata al linguaggio di programmazione che permette di aggiungere metodi personalizzati a qualsiasi classe/interfaccia del .NET Framework, incluse le classi usate come classi di base (un esempio per tutte: la classe object),  “estendendo” appunto il tipo originale.

In tal modo è possibile estendere il contratto pubblico  esposto dalla classe /interfaccia senza per questo ricorrere all’ereditarietà. Utilizzando invece quest’ultima tecnica si era limitati alle solo classi ereditabili (non dichiarate “sealed”, come ad esempio la classe System.String), e soprattutto si correva il rischio di compromettere la consistenza dell’oggetto nel caso in cui facendo l’override di un metodo ci si dimenticava di richiamare il corrispondente metodo della classe di base.

A volte molti programmatori ricorrono all’ereditarietà per la semplice esigenza di aggiungere propri metodi ad una classe, non certo per ridefinire il comportamento della classe di base.

Inoltre, l’Intellisense di Visual Studio fornisce pieno supporto per gli Extention Methods, visualizzandoli correttamente all’interno del tipo che estendono, con una icona personalizzata.

Guardando i numerosi esempi di “Extention methods” disponibili sulla rete ho notato però che questi metodi sono inclusi in una classe avente un namespace custom, esempio Mycomponent.Extentions.StringExtentions per gli extention methods della classe String. Questo è a mio avviso un errore, in quanto così facendo l’Intellisense di Visual Studio non mostra gli Extention Methods di una certa classe se il relativo namespace non viene importato (cosa ovvia). Questo comportamento sicuramente disorienta, in quanto dato un certo tipo la lista dei suoi metodi visualizzata è parziale.

Quindi, gli Extention Methods di un tipo dovrebbero essere raggruppati un una classe inserita nello stesso namespace del tipo che estendono. Nell’esempio precedente per estendere la classe System.String la relativa classe statica dovrebbe essere inclusa nel namespace System.

In questo modo, importando un solo namespace sono visibili sia i metodi pubblici che i metodi estesi.

D’altronde, questo è il comportamento dello stesso Framework. Ad esempio tutti gli Extentions Methods della classe System.Data.DataTable sono racchiusi nella classe DataTableExtentions inserita nel namespace System.Data.

Per chi utilizza Outlook in modo intensivo questo è davvero un must-have tool. Sto parlando di Xobni, un add-in per Outlook 2003/2007 che permette di gestire i messaggi di posta in modo molto efficiente. Tra le sue caratteristiche segnalo:

1. Efficientissimo motore di ricerca di messaggi e/o persone con nutrito numero di opzioni;
2. Gestione dei messaggi in thread;
3. Estrazione automatica del numero di telefono del mittente dal messaggio di posta (spettacolare);
4. Ricerca istantanea degli allegati legati ad un particolare mittente;
5. Creazione di mail di invito ad un evento con estrazione automatica dei periodi di disponibilità dal proprio calendario;
6. Statistiche estremamente dettagliate sulle mail scambiate con ogni mittente;
7. Navigazione della mailbox in base al profilo della persona;

La feature che personalmente trovo estremamente comoda è la ricerca degli allegati legati ad una particolare persona. Quante volte si perde tempo a cercare un allegato di cui ci ricordiamo che la tal persona ce lo ha inviato senza ricordarci però in quale preciso messaggio ?

L’add-in è gratuito (particolare di una certa importanza), è attualmente scaricabile in versione beta con aggiornamento automatico alle versioni successive, è scritto da una azienda californiana, Xobni appunto, il cui significato è, curiosità, “Inbox” letto al contrario, richiede la presenza del .Net Framework 2.0 o successivo.

Davvero un ottimo tool.

Se lavorate con LINQ, questa pagina è utile averla sempre a portata di mouse. 

101 LINQ Samples

“What’s it mean? Well, it’s a code that describes the processes and tools that I like to use to develop”

Ecco il mio:

Ero praticamente certo che sarebbe uscita la hotfix giusta per me riguardante Visual Studio 2008.

Negli ultimi tempi ho sperimentato in prima persona rallentamenti eccessivi e chiaramente molto fastidiosi nell’utilizzo di alcune funzionalità dell’IDE e precisamente:

• Passando alla vista Design di una Web Form;
• Passando alla vista Html Source di una Web Form;
• Compilando un progetto web di grosse dimensioni;

Oggi ho scoperto che da pochissimo tempo è disponibile una hotfix che risolve tutti e tre i problemi sopradescritti.

Link per il 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.

Tra i tools che ogni buon sviluppatore dovrebbe possedere non può mancare quello forse più classico e scontato, ovvero un software che compara il contenuto di 2 files ed evidenzia le differenze.

A meno di non voler usare le funzionalità di comparazione presenti nei vari software di controllo del codice sorgente, il compare di files è una operazione abbastanza frequente.

Ho provato vari tools di comparazione, quello che uso e che a mio parere è uno dei più validi (soprattutto perchè a free :)) è DiffMerge ver. 3.1.0.

Oltre alla classica funzione di comparazione di 2 files con indicazione grafica delle differenze, questo software contiene utilissime feature quali:

a) merging dei contenuti operando su 3 files;

b) comparazione di 2 cartelle con indicazione dei files mancanti e dei files con contenuto diverso;

c) aggiunta di un comodo menù contestuale in Windows Explorer per una rapida comparazione di files;

d) è multipiattaforma;

e) (già detto) è gratuito;

Ho installato già da un po’ di tempo i PowerCommands for Visual Studio 2008 (una estensione dell’IDE per aggiungere funzionalità) e devo dire che sono davvero utili.

Tra le funzionalità più interessanti segnalo:

–Remove and Sort Usings: a livello di progetto, ordina gli statements using e rimuove automaticamente quelli inutilizzati (disponibile solo per progetti scritti in C#);

–Collapse projects: come dice lo stesso nome, “collassa” uno o più items (non necessariamente progetti) per migliorare la visione d’insieme della solution;

–Edit Project File: carica il file di progetto nell’editor (dopo aver scaricato il progetto stesso), fornendo la sintassi colorata di un file XML;

–Open Command Prompts: apre il prompt dei comandi di Visual Studio a partire dal path fisico dell’item selezionato;

–Clear Recent Project List: permette di eliminare tutti o alcuni progetti aperti di recente dalla lista. Se non ricordo male senza questo tool è necessario editare il registro per ottenere lo stesso risultato.

Il tool dispone di altri comandi interessanti.

In questi giorni mi è capitato frequentemente di leggere su blogs e forum vari commenti entusiastici sull’adozione delle ultime tecnologie appena sfornate – parlo di Silverlight, Ajax e LINQ, le quali hanno ormai preso prepotentemente piede nello sviluppo di applicazioni. Premesso che utilizzo anch’io sia Ajax che LINQ, ritengo che il tutto debba essere calato nel contesto opportuno di utilizzo, senza lasciarsi prendere troppo dall’entusiasmo come invece vedo che accade. Può sembrare scontato ma la realtà è ben diversa. Comprendo perfettamente che lo sviluppatore esperto e soprattutto appassionato affronti le sfide tecnologiche che molto frequentemente il nostro mestiere ci offre, con l’entusiasmo di un ragazzino, ma credo che ultimamente si stia un po’ esagerando. Sembra quasi che oggiogiorno ogni applicazione web debba essere necessariamente Ajax-enabled e sembra che LINQ to SQL, o meglio gli ORM in generale, abbiano sostituito di colpo l’utilizzo di strumenti per così dire tradizionali quali le store procedure, diventate improvvisamente uno strumento superato. Riflettendo un attimo, questo entusiasmo non è certo una novità nel mondo delle tecnologie software: come esempio non isolato, ricordo che  successivamente all’introduzione dei web services tutti gli utilizzatori di software hanno adottato incondizionatamente questa tecnologia anche se le loro applicazioni non erano affatto interoperanti se non con sè stesse…L’unificazione del paradigma di sviluppo in funzione dei diversi contesti di utilizzo si è verificata solo con l’avvento di WCF. Accadrà lo stesso con le attuali tecnologie ?