Chi sviluppa in Asp.Net 2.0 sa che è possibile lanciare una web application senza effettuare nessuna compilazione, in quanto di default ogni pagina viene compilata al "volo".
Premetto che in questo post non scriverò dei diversi svantaggi (di reali vantaggi sinceramente non sono ancora riuscito a trovarne) che presenta questa "metodologia" bensì di alcuni problemi con cui mi sono dovuto scontrare ultimamente.
Lo scenario è un grosso progetto web basato sull'architettura di DNN.
Per precompilare la parte web ho utilizzato l'add-in Web Deployment Project, il quale consente di compilare un sito web in uno ( alla Visual Studio .NET 2003) o più assembly.
Per avere una completa descrizione delle opzioni che offre questo add-in vi rimando al seguente articolo: Using Web Deployment Projects with Visual Studio 2005.
Inoltre per completezza è bene anche una lettura a VS 2005 Web Deployment Projects di Scott Guthrie.
Ho optato per un unico assembly, quindi ho lanciando il build.
Ho subito ottenuto un errore che di per sè non vuol dire praticamente nulla:
"aspnet_merge.exe" exited with code 1
Per avere un'informazione più utile bisogna modificare il livello di verbosity dell'output del MS-Build:
Tools > Options > Project and Solution > Build and Run
Dalla tendina MSBuild project build ouptut verbosity selezionate la voce Diagnostic o Detailed.
Ricordatevi di attivare la finestra di output:
View > Output
A questo punto è stato necessario modificare una serie di classi che presentavano namespace identici.
Questo provoca "collisioni" quando il tool cerca di generare un unico assembly.
Primo consiglio quindi, è quello di definire sempre per le pagine un namespace in modo esplicito non facendo ricorso alla "tecnica" del copy & paste.
Il secondo passo è stato quello di copiare il progetto compilato nella web folder e lanciarlo, pensando di aver svolto il grosso del lavoro, ma invece ecco che spunta un altro errore:
Could not find a part of the Path XXX\App_GlogalResources\Locales.xml
Dopo una breve ricerca con "san google" trovo che una possibile soluzione consiste nel cancellare dalla root del progetto il file PrecompiledApp.config.
Erroneamente, senza pormi troppe domande, ho cancellato il suddetto file.
In effetti dopo questa semplice modifica si presenta un altro errore:
Could not find file 'c:\DotNetNuke.config'.
Debuggando è saltato fuori che alcune property dichiarate nell'assembly DotNetNuke non venivano settate.
Preciso che nel progetto queste property vengono settate nel file Global.asax, quindi mi sono chiesto perchè quest'ultimo non veniva in fase di esecuzione "analizzato".
Credo che il motivo sia collegato alla cancellazione del file PrecompiledApp.config.
Il file contiene il numero di versione del tool di precompilation ( 2 per Asp.Net 3.5) e se il sito è in grado di essere aggiornato:
1: <precompiledApp version="2" updatable="true"/>
Tiene traccia delle opzioni di deploy dell'applicazione ed indica ad Asp.Net se deve compilare ogni file ad ogni richiesta:
L'attributo updatable impostato a true è applicabile alle pagine .aspx, agli user control ( .ascx), master file ma non al file Global.asax che viene compilato ( bin\App_global.asax.compiled).
L'ultima cosa che mi rimaneva da risolvere era quella di consentire alla cartella App_GlobalResources di risiedere nella directory di distribuzione.
L'unico workaround che sono riuscito ad adottare è stato quello di modificare nel file Localization.vb dell'assembly DotNetNuke, situato in:
\Library\Components\Localization
la costante ApplicationResourceDirectory come segue:
1: Public Const ApplicationResourceDirectory As String = "~/DNN_GlobalResources"
0 commenti:
Post a Comment