Il nuovo modello di compilazione-deployment di ASP .NET 2.0 non è certamente facile da usare e nemmeno intuitivo, soprattutto per chi proviene da ASP .NET 1.0/1.1.
Non a caso Microsoft ha rilasciato un add-in, il Web deployment Project, praticamente in concomitanza con l’uscita di Visual Studio 2005, che permette di utilizzare il modello di compilazione di ASP.NET 2.0, pur garantendo un alto grado di flessibilità; infatti è possibile compilare una applicazione web in un singolo assembly, oppure in un assembly separato per ogni sua directory, oppure ancora in un assembly separato per ogni pagina/controllo.
In aggiunta, poco tempo dopo è stato rilasciato un’altro add-in, il Web Application Project, di cui magari parlerò in in post a parte. Per il momento mi limito a dire che ambedue questi add-in non sono supportati da Visual Studio in versione Visual Web Developer.
Se si prova ad lanciare in esecuzione una applicazione ASP .NET 2.0, ogni pagina è compilata “al volo” su richiesta (comportamento di default), e per ogni pagina richiesta viene generato un singolo assembly a cui viene attribuito un nome “non user-friendly”. Questo provoca pochissimi vantaggi, anzi, a mio avviso uno solo, e gravi svantaggi. A questa conclusione ci sono arrivato dopo parecchi mesi di utilizzo di Visual Studio 2005, praticamente dalle versioni beta, a dispetto di un iniziale entusiasmo per il nuovo modello di compilazione. Infatti, in apparenza basta far puntare VS ad una directory del file system che contiene una web application e lanciarla in esecuzione per vederla nel browser senza una sua preventiva compilazione. Non solo, è anche possibile modificare il sorgente della pagina mentre la stessa è in esecuzione, salvare la pagina per vedersi applicate immediatamente le modifiche al codice sorgente senza una ricompilazione (questo piccolo apparente “miracolo” è dovuto al fatto che ogni pagina è compilata in un assembly separato, quindi è possibile scaricare dalla memoria il singolo assembly e ricaricarlo ad ogni modifica della pagina; questo è l’unico vantaggio di cui parlavo prima) . A prima vista tutto ciò può sembrare favoloso, in realtà questo comportamento nasconde parecchie insidie. Prima di tutto affinchè questo modello funzioni è necessario copiare sulla macchina di deployment anche i sorgenti della propria applicazione, praticamente occorre replicare il contenuto dell’applicazione presente sulla propria macchina di sviluppo. Questa è, a mio avviso,una condizione inaccettabile su applicazioni pubbliche che manipolano dati sensibili o che effettuano transazioni economiche; forse è appena appena accettabile su applicazioni funzionanti in intranet che non trattano dati personali.
Inoltre, il nome dell’assemby contenente la pagina compilata è generato a run-time ed univoco, anche se viene ricompilata la stessa pagina compilata precedentemente. Questo significa che è impossibile per una pagina X mantenere un riferimento alla pagina Y, perchè la classe di quest’ultima ed il suo assembly saranno “nominati” solo a run-time con un nome non prevedibile. Questo è davvero un grande problema per coloro che usano web control caricati dinamicamente a run-time, perchè significa che non è possibile ottenere un riferimento “strongly typed” ad un web control caricato dinamicamente, ma solo un riferimento generico “UserControl”, a meno di non utilizzare il tag @Register sulla pagina (il quale forza l’assembly della pagina che contiene il tag a mantenere un riferimento all’assembly che contiene lo user control), oppure, se l’applicazione è compilata in assembly separati per ogni sua directory, occorre che la pagina che referenzia lo user control e quest’ultimo risiedano nello stesso assembly, quindi nella stessa directory fisica.
L’add-in Web Deployment Project permette di “precompilare” l’intero sito in uno o più assembly, e di assegnare a quest’ultimi nomi statici, quindi ripetibili, che permettono alla classe che contiene il codice per una data pagina di essere referenziata senza problemi da un assembly/classe esterna in quanto il suo nome non cambia ad ogni ricompilazione. Utilizzo questo add-in praticamente da sempre e sinceramente, ma è solo un parere personale su cui mi piacerebbe ascoltare esperienze di altri sviluppatori, non riesco ad immaginare una web application che non ne faccia uso, chiaramente intendo applicazioni line of business ad alta disponibilità che girano su server pubblici con un alto indice di richieste.
Comments are closed.