Maurizio Tammacco's blog

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.

Questa è la mia agenda:

Qualche suggerimento ?

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" come evidenziato sotto:

• 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.