Breaking changes tra ASP.NET 1.1 e 2.0

Mentre il PSS continua a cercare di capirci qualcosa (entro fine settimana dovremmo avere l'esito), io la "migrazione" di applicazioni vere dalla 1.1 alla 2.0 l'ho già fatta :)

Non ho ancora pensato, perchè voglio avere un po' più di esperienza sui possibili problemi, a portare (hint: ricompilare) applicazioni 1.1 di clienti sulla v2, ma con le mie posso farlo, al limite poi mi licenzierò da solo :)

Parlottando con Cristian e Ricky non siamo riusciti ad immaginare un problema bloccante, anche perchè scomporre la soluzione in parti diverse non è servito: togliere un Module per volta, un Handler o qualsiasi altra cosa "delicata" non ha cambiato il risultato.

A questo punto qualcuno potrebbe dire: perchè vuoi per forza usare la v2 quando con la 1.1 funziona tutto bene? Risposta semplice: la v2 ha miglioramenti sostanziali per sicurezza, stabilità e velocità rispetto alla 1.1. Come mi ha confermato Alessandro, Lead PM del CLR incontrato al lancio di VS 2005, questo scenario è supportatissimo ed anzi è opportuno prevederlo, considerati i benefici della nuova versione.

Comunque, il titolo del post dovrebbe aiutarvi nella migrazione di applicazioni dalla 1.1 alla v2 e quindi meglio focalizzarsi su questo argomento :)

Da qualche giorno Microsoft ha pubblicato una lista di breaking changes tra le due versioni e qui c'è quella per ASP.NET 2.0. Io queste cose le ho imparate sulla mia pelle, cominciando a fare il porting il primo giorno di disponibilità della RTM, ma va bene, è il prezzo di essere early adopters.

Il primo problema che noterete è che i ticket di autenticazione non funzionano più, dato che la chiave cambia e quindi vengono invalidati. La cosa strana è che vi trovate l'event log pieno di errori che ve lo segnalano. Immaginate cosa succede se 200-300 utenti accedono al sito e vi riempiono il log...

L'altra differenza è che mentre con la 1.1 il ticket poteva essere passato via URL, ad esempio per fare single sign-on, con la v2 questo scenario non è previsto e quindi vi tocca inventarvi qualcos'altro. E tra l'altro migliorerete anche la sicurezza, dato che non passa la stringa di auth via URL.

L'altra cosa fastidiosa che ho sperimentato è che, utilizzando ASP.NET 2.0 i Build Providers per tutto, praticamente, se mappate una risorsa non standard dovete associargli un BuildProvider di default. Questo perchè ASP.NET 2.0, così come IIS 7, ha un nuovo meccanismo di gestione delle risorse non-ASP.NET, che sono associate di default ad un handler, DefaultHttpHandler, che in pratica dopo aver preso in carico la richiesta esegue l'handler associato in IIS. Per capirci, potete mappare ASP in modo che utilizzi la FormsAuth di ASP.NET! :)

Lo scenario è spiegato a pagina 2 del mio articolo di introduzione, pubblicato all'interno delle 2 settimane di speciale.

Comunque, perchè le estensioni custom possano funzionare (e ne siamo pieni, da zip a vsi, per non parlare di live) è necessario specificare tutte le classi responsabili per la compilazione all'interno del web.config. Ecco ad esempio cosa ho dovuto fare per live:

<compilation>
  <buildProviders>
    <add extension=".album" appliesTo="Web" type="System.Web.Compilation.PageBuildProvider" />
    <add extension=".img" appliesTo="Web" type="System.Web.Compilation.PageBuildProvider" />
    <add extension=".photo" appliesTo="Web" type="System.Web.Compilation.PageBuildProvider" />
   <add extension=".rss" appliesTo="Web" type="System.Web.Compilation.PageBuildProvider" />
  </buildProviders>
</compilation>

L'attributo appliesTo fa sì che il build provider funzioni solo sulla parte "web", che è in pratica tutto ciò che non sia app_code (il cui valore sarebbe Code) :) Sui Build Providers, un approccio molto potente alla costruzione di applicazioni web, torneremo di sicuro nei prossimi mesi con almeno un articolo.

Altro problema, quello segnalato da Andrea Zani su XslTtransform. Qui entriamo in realtà nell'area delle classi marchiate come Obsolete, e rischiamo di perderci. Personalmente questi "problemi" li ho classificati come non bloccanti, quindi da "migrare" con calma, sempre tenendo presente che è meglio trattare un warning alla stregua di un errore. Sempre su questa falsa riga ci sono System.Configuration.ConfigurationSettings.AppSettings, System.Web.Mail.SmtpMail e MailMessage, per citare i più diffusi.

Insomma, devo dire che il porting è stato molto semplice ed anche abbastanza indolore, specie perchè ho usato la Team System Software Architect, quindi non mi sono limitato ad una Express, ma già con la Standard avete il supporto per le class library, funzionalità essenziale. L'unica nota degna di rispetto è che finalmente posso usare VS 2005 anche per l'editing delle pagine web, perchè non mi genera schifezze come VS.NET 2003! :)