ASP .NET

L’evento Application_Start ed il suo corretto utilizzo

Maurizio — Tue, 23 Feb 2010 22:29:00 GMT

Regola importante in una applicazione ASP .NET:

durante l'evento Application_Start dovrebbero essere assegnate solo variabili statiche e mai variabili d'istanza; ciò è dovuto al fatto che questo evento viene sollevato solo 1 volta durante il ciclo di vita dell'applicazione e, insieme all'evento Application_End, non è legato alla istanza in esecuzione della classe HttpApplication ma, al contrario, entrambi sono considerati eventi speciali.

Infatti, ogni applicazione ASP .NET in esecuzione è associata ad un oggetto HttpApplication, capace di gestire una richiesta alla volta. Durante il suo ciclo di vita possono essere create più istanze della classe HttpApplication, ognuna delle quali in ottica di ottimizzazione delle performance può essere riciclata. Tuttavia, i due eventi sopra citati non vengono sollevati per ogni istanza creata di HttpApplication ma, come detto, solo 1 volta durante la vita di una applicazione.

Un membro d'istanza creato in Application_Start quindi sarebbe visibile solo per la prima istanza creata di HttpApplication e non anche per le successive.

Viceversa, l'evento sollevato per ogni istanza creata di HttpApplication è invece Application_Init.

ASP .NET 4.0 #3 Ciò che non è cambiato

Maurizio — Tue, 24 Nov 2009 21:42:00 GMT

ASP .NET 4.0 è ormai alle porte, con la versione beta è possibile scoprire le novità rispetto alla versione precedente, e non sono certamente poche, ma a livello di controlli lato server ce ne sono alcuni praticamente immutati rispetto alle precedenti versioni. Mi riferisco ad esempio al controllo Http File Upload, rimasto identico nelle varie versioni di ASP .NET che si sono succedute. Questo controllo soffre di qualche problema e non è certo il massimo in ottica web 2.0, ovvero su siti dove è richiesto una elevata user experience.

A meno di non utilizzare un controllo di terze parti probabilmente a pagamento, occorre fare i conti con il look del controllo rimasto identico nel tempo, con l'assenza di funzionalità oggi richieste quali ad esempio la barra di progressione dell'upload in corso, e soprattutto con un fastidioso comportamento "by design", ovvero la perdita del contenuto (il nome completo di percorso del file scelto) ad ogni postback della pagina; quest'ultima caratteristica è resa necessaria da motivi di sicurezza.

Se la pagina dispone di altri controlli che generano un postback, es. una dropdownlist, l'unico escamotage è quello di rendere il controllo File Upload l'ultimo controllo che genera postback in ordine di visualizzazione, in modo da invogliare l'utente ad interagire per ultimo con esso. In caso contrario, un postback della pagina provocherà la perdita del suo contenuto, cioè del nome del file scelto, ed ovviamente obbligherà l'utente a scegliere nuovamente il file da inviare.

L’evento page load è eseguito 2 volte

Maurizio — Sat, 14 Nov 2009 23:17:00 GMT

Convertire un progetto ASP .NET dalla versione 1.1 ad una versione successiva del .NET Framework nasconde un inconveniente a cui occorre porre rimedio manualmente.

L'inconveniente è dovuto alla introduzione delle partial class a partire dalla versione 2.0 del .NET Framework, in contrapposizione al codice generato dal designer nella versione 1.1.

Questo fa si che importando il codice sorgente nella nuova versione utilizzata ci si ritrovi, ad esempio, con un event handler come questo nel metodo InitializeComponent

private void InitializeComponent() 

{ 

    this.Load += new System.EventHandler(this.Page_Load); 

}

Questo innocente codice derivante dalla conversione fa in modo che l'evento Page Load sia generato 2 volte, una volta dall'handler presente nella partial class ed una volta da quello presente nel metodo InitalizeComponent.

Per eliminare questo fastidioso inconveniente è sufficiente rimuovere l'handler presente nel metodo InitializeComponent

ASP .Net e i thread secondari

maurizio — Mon, 28 Sep 2009 00:24:09 GMT

Interessantissimo post di Stefano Pronti del nuovo blog MSDN di Supporto Tecnico agli Sviluppatori, che spiega le disastrose conseguenze di non richiamare il metodo Dispose su risorse unmanaged, utilizzate all'interno di una web application.

Per farla breve, le risorse unmanaged utilizzavano un thread secondario rispetto a quello che prende in carico la web request, ed in questo thread secondario veniva sollevata una eccezione non gestita durante la fase di finalizzazione del garbage collector, che, come è noto, viene eseguito in un thread diverso.

In questo caso il comportamento di ASP .NET a partire dalla versione 2.0 è quello di interrompere immediatamente il processo in esecuzione, con conseguenze facilmente immaginabili.

Ho già parlato qui di questo comportamento di ASP .NET e di come sia possibile utilizzare la modalità pre-versione 2.0 di gestione delle eccezioni non gestite sollevate all'interno di thread diversi.

Anche a me è capitato di dover "impazzire" con una applicazione in produzione, abbastanza vasta, che soffriva di frequenti ed improvvise cadute della sessione corrente, con enorme disagio degli utenti.

Nel caso specifico non è stato indispensabile attaccare un debugger per ottenere il dump della memoria al momento dell'eccezione, è bastato debuggare il codice, che non conoscevo neanche bene, e scoprire che venivano creati thread aggiuntivi (!?) il cui codice, in particolari circostanze, sollevava l'eccezione fatale che provocava il riavvio del worker process.

HttpResponse.ApplyAppPathModifier

maurizio — Tue, 27 Jan 2009 08:00:20 GMT

Se si usano le sessioni ASP .NET coockieless, ovvero sessioni in cui il SessionID viene inserito nell'url nella seguente forma:

/App/(S(avsbnbml2n1n5mi5rmfqnu65))/default.aspx

il metodo ApplyAppPathModifier della classe HttpResponse risulta estremamente utile, poichè, passandogli come parametro stringa un path virtuale, restituisce lo stesso path con il SessiondID inserito correttamente nell'url, sollevando lo sviluppatore dalla costruzione manuale dello stesso. Ciò risulta evidente ogni qual volta è necessario utilizzare url caricati dinamicamente.

IIS ASP .NET Tab missing

maurizio — Tue, 10 Jun 2008 21:54:08 GMT

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.

Messaggio di errore Ambiguous match found e httpParseException

maurizio — Mon, 17 Mar 2008 03:58:15 GMT

Scenario: web application che utilizza la versione 1.1 di ASP .NET migrata direttamente alla versione 3.5. Dopo la migrazione su una delle pagine ASPX viene sollevato una HttpParseException durante il caricamento della stessa. L'eccezione in questione, come si evince dal nome, viene generata dal runtime di ASP .NET quando il parsing di una pagina ASPX fallisce a runtime. Il messaggio di errore recita "Ambiguous match found", e quindi non aiuta granchè. La cosa curiosa è che l'eccezione non si verifica in ambiente di sviluppo ma solo sulla versione di deploying dell'applicazione, quindi non è "debuggabile" in Visual Studio 2008 ( a meno di non effettuare un debug in remoto, cosa quasi mai possibile in ambiente di produzione) , e quindi non è di facile risoluzione.

In questi casi la prima cosa che penso è: sicuramente altri developers sparsi per il mondo hanno già sperimentato lo stesso problema, quindi mi metto a perlustrare blogs e forum e normalmente alla fine il problema si risolve !

E così è stato anche stavolta, anche se le cause di questa eccezione possono essere diverse e quindi non esiste una soluzione universalmente applicabile.

Alcune delle cause che possono produrre una httpParseException sono, in ordine sparso:

la pagina contiene un campo hidden che ha un ID con lo stesso nome di una variabile querystring usata dalla stessa pagina;
la pagina ha un controllo (non ascx) inserito nel file ASPX (e quindi inserito nella partial class non visibile), e nel code-behind della stessa è dichiarato un altro controllo protected con lo stesso nome;
la pagina contiene un controllo ASCX con lo stesso nome di un controllo nativo ASP .NET;

Tutte queste situazioni generano evidentemente una ambiguità dei tipi, che porta all'eccezione.

Inoltre, effettuando un deploy del sito con l'opzione "non aggiornabile", ovvero deselezionando l'opzione "Allow this precompiled site to be updateable", l'eccezione dovrebbe scomparire, salvo poi approfondire le sue cause e riabilitare nel caso l'opzione.

Partial rendering troubleshooting

maurizio — Thu, 13 Mar 2008 05:24:00 GMT

Regola importante: l'update parziale di una pagina ASP .NET 2.0 (o successivi) attraverso l'UpdatePanel di Ajax non funziona in presenza di questo tag nel file di configurazione dell'applicazione (o nel machine.config):

Infatti, con questa impostazione la proprietà "SupportPartialRendering" dell'oggetto ScriptManager ritorna il valore false.

Il tag in questione imposta la modalità di rendering dei controlli, es.: in modalità compatibile XHTML (mode="Transitional" o "Strict") oppure no (mode="Legacy").

In ASP .NET 1.1 i controlli subivano un rendering non XHTML compatibile, e questo comportamento è stato modificato in ASP .NET 2.0, che invece effettua il rendering XHTML compliant. Questo significa che se si migra una applicazione scritta con la versione 1.1 del .NET Framework ad una versione più recente, il wizard di migrazione imposta l'xhtml conformance mode in modalità Legacy, provocando di fatto il mancato funzionamento del partial rendering. Per risolvere il problema è sufficiente impostare il tag mode a "Transitional" (valore di default) oppure "Strict", oppure rimuovere il nodo in modo tale da assegnargli il valore di default, es.:

<xhtmlConformance mode="Transitional"/

TextBox ReadOnly in .NET 2.0 e successivi

maurizio — Tue, 26 Feb 2008 03:13:00 GMT

Il controllo TextBox di una web application dispone della proprietà ReadOnly che, ovviamente, impedisce l'interazione dell'utente con il controllo quando è impostata a True.

Ma c'è un particolare importantissimo da considerare: a partire dalla versione 2.0 del .NET Framework il contenuto di un textbox in modalità "ReadOnly" è inviato al server durante un postback della pagina, ma il server ignora questo valore; in altre parole il contenuto del textbox viene perso durante un postback. Questo comportamento mira ad impedire attacchi alla sicurezza, che potrebbero modificare un valore che dovrebbe essere mantenuto inalterato.

La perdita del valore del textbox può essere inaccettabile in certi contesti applicativi e potrebbe essere necessario applicare il comportamento in essere prima del Framework 2.0. Per far ciò è necessario impostare la proprietà ReadOnly come attributo del controllo, in questo modo:

TextBox1.Attributes.Add("readonly","readonly")

e non impostando a True la relativa proprietà.

Così facendo il valore del textbox (ovvero la sua proprietà Text) viene inviato al server durante il postback ed è altresì disponibile per l'elaborazione.

UPDATE: questo aggiornamento è, diciamo così, dovuto: il "copyright" di questa scoperta che ha portato via parecchio tempo prima di venirne a capo non è mio ma della mia collega di lavoro Ines. Io ho solo raccolto il troubleshooting per aiutare altri programmatori come un tempo altri programmatori hanno aiutato me

Eccezioni non gestite in ASP .NET 2.0

maurizio — Thu, 10 Jan 2008 12:43:00 GMT

Le eccezioni non gestite generate da una applicazione ASP .NET compilata con la versione 2.0 del .NET Framework sono trattate diversamente da quanto avveniva con le applicazioni ASP .NET compilate con la versione 1.0/1.1. Queste ultime semplicemente ignoravano le eccezioni non gestite sollevate all'esterno del contesto corrente, es. un thread diverso da quello principale, mentre le eccezioni sollevate all'interno del contesto erano trattate normalmente come qualsiasi eccezione non gestita. Con il .NET Framework 2.0 questo comportamento è cambiato: le eccezioni non gestite sollevate fuori dal contesto provocano l'immediata interruzione del worker process e conseguentemente dell'applicazione. L'unica traccia è un laconico messaggio nell'event viewer (System Log) del tipo "DefaultAppPool terminated unexpected", seguito da un ancor più generico messaggio nell'Application Log (Event Source: .NET Runtine 2.0 Error Reporting).

Ma questo comportamento (il default) è legato ad una precisa policy di gestione delle eccezioni non gestite e può essere modificato in 2 modi:

-Aggiungendo le seguenti righe nel file Aspnet.config:
        <configuration>
            <runtime>
                <legacyUnhandledExceptionPolicy enabled="true" />
            </runtime>
        </configuration>

        per fare in modo che le eccezioni non gestite siano trattate come nel .NET Framework 1.0/1.1, ovvero ignorate (scelta non
        raccomandata da Microsoft)

-Creando un opportuno httpModule che si registra per l'evento AppDomain.CurrentDomain.Unhandledexception, attraverso il quale loggare i dettagli dell'eccezione non gestita verificatasi.

Il tutto è documentato in questo articolo, con un esempio di httpModule.