Maurizio's blog 3.0

Stasera ho partecipato alla prima chat tecnica organizzata da Emanuele, a cui ha partecipato anche Riccardo Golia, Vito Arconzo, Alessandro Melchiori, Roberto Vespa e MatteoB. La chat si è svolta via MSN, e l’argomento era “i design pattern”. Devo ammettere che ero un pò scettico sulla riuscita della iniziativa, temevo che una cosa del genere fatta via Messenger avrebbe retto poco. Sono contento di essermi sbagliato, perchè non solo siamo riusciti bene o male a seguire quello che gli altri avevano da dire sull’argomento, in poche parole ad interagire nonostante a volte partissero 2 o 3 thread contemporaneamente, ma siamo anche riusciti ad “accendere” le discussioni su argomenti per me molto di attualità e sentiti, legati chiaramente al nostro mestiere di consulente informatico. Quindi è stata una bella esperienza, che ripeterei senza lasciarmelo dire 2 volte. La prossima volta Emanuele ha in mente di dedicare la chat alla programmazione “Agile”, e per tenere alto il livello dovrebbe essere dei nostri un vero esperto in materia, Luca Minudel. Chiunque voglia partecipare può contattarmi attraverso il form contact di questo blog.

Nonostante qualche commento negativo letto in Rete, a me il comportamento di ASP .NET 2.0 in presenza del file app_offline.htm nella root della web application mi sembra abbastanza comodo e funzionale. Ricordo che questo file è utile quando si è in fase di manutenzione della propria applicazione web e si vuol fornire un messaggio “user friendly” agli utenti informandoli che l’applicazione non è momentaneamente disponibile, o qualsiasi cosa si voglia. In presenza di un file con tale nome infatti, l’engine di ASP .NET 2.0 effettua lo shutdown dell’applicazione, scarica l’appDomain e risponde ad ogni richiesta dei files normalmente gestiti dallo stesso engine con il file app_offline.htm appunto, permettendo in questo modo di non far incorrerere in errori eventuali richieste che avvengono mentre il sito è in manutenzione. Basterà poi rinominare, cancellare o spostare il suddetto file affinchè le pagine richieste siano elaborate nel modo consueto. Comodo no ? Ma cè un problema, aggirabile, ma pur sempre un problema. Internet Explorer 6.0 ha una impostazione chiamata “Mostra messaggi di errore HTTP brevi”. Questa impostazione di default è vera, e significa che qualsiasi messaggio HTTP diverso da 200 il cui contenuto non eccede il 512 byte, verrà mostrato da IE in modo cosiddetto “user frendly” per l’utente, fornendo un messaggio generico di errore che non lascia capire nulla circa la vera causa dell’errore. Qui nasce il problema: se il file app_offline.htm è più piccolo di 512 byte non è correttamente visualizzato ma al suo posto viene ritornato un errore HTTP (quindi un codice diverso da 200) che, in presenza della impostazione “Mostra messaggi HTTP brevi” su “on” provoca un errore generico. Non capisco come un messaggio di errore generico possa essere ritenuto “user friendly” per l’utente. Per la mia esperienza non fa altro che disorientarlo ancor di più. La soluzione al problema è ovviamente creare il file app_offline con una dimensione maggiore di 512 byte (oppure fare in modo che lo sia aggiungendo ad esempio commenti fittizi nel codice HTML), oppure disabilitare l’impostazione “mostra messaggi di errore http brevi”

Applicare un service pack è una operazione che andrebbe meditata un pò, almeno andrebbe fatta dopo aver letto quali sono le fix apportate e quali sono gli eventuali impatti. A volte un però l’applicazione di un service pack provoca che una qualche funzionalità smette di ….funzionare. A parte gli scherzi, applicando il service pack 4 a Sql Server 2000 diventa impossibile aprire un trace table con Sql Profiler a causa del seguente errore bloccante:

“Failed to open a table”.

Soluzione immediata ? Aprirlo con il profiler di Sql Server 2005.

Il tutto è ampiamente documentato in questo articolo della KB Microsoft 

Una cosa che non sapevo, e che desidero condividerla con gli (eventuali) lettori di questo blog: un link demand a livello di metodo sovrascrive sempre un link demand a livello di classe anche se trattasi di permessi differenti.

Esempio, data questa classe:

[FileIOPermission(SecurityAction.LinkDemand, Unrestricted=true)]
public class ClassA
{
    [EnvironmentPermission(SecurityAction.LinkDemand, Read="VAR1" )]
    public void Method1)
    {
    }
}

Il link demands a livello di metodo effettua l’override di quello a livello di classe, anche se si tratta di permessi differenti. In questo caso il link demands EnvironmentPermission sostituisce il link demands FileIOPermission, con la conseguenza che quest’ultimo permesso non viene richiesto per il metodo in questione.

Morale, occorre esplicitamente re-indicare i link demands a livello di classe su un metodo, se quest’ultimo è decorato già con un link demands.

Esempio corretto:

[FileIOPermission(SecurityAction.LinkDemand, Unrestricted=true)]
public class ClassA
{
   [FileIOPermission(SecurityAction.LinkDemand, Unrestricted=true)]
   [EnvironmentPermission(SecurityAction.LinkDemand, Read="VAR1" )]
   public void Method1)
   {
   }
}