Questo articolo non è un tutorial su ASP.NET scritto nello stesso stile di quelli che si trovano in abbondanza in Rete, quasi sempre troppo prolissi sui concetti fondamentali e poveri di esempi pratici.
Spesso abbiamo bisogno di poche righe che ci introducano immediatamente nel nucleo della materia, lasciandoci così la possibilità di concentrarsi successivamente sui dettagli implentativi.
A prima vista le operazioni che si devono effettuare per passare da ASP ad ASP.NET non sono molte né complicate e quello che si ottiene è sbalorditivo.
Sopratutto se, già in ASP, si "pensa" e si scrive codice OOP (Object Oriented Programming). Le possibilità offerte dal nuovo framework sono, a dir poco, stupefacenti.

Ecco, dunque, l'elenco dei passi da seguire per passare ad ASP.NET dopo che l'installazione del Framework .Net e Visual Studio .NET è stata completata:

1. creare una copia della directory (es. /MYSITE) contente il sito in ASP e rinominarla (es. /MYSITE_NET);
2. creare, tramite IIS o PWS, una directory virtuale che punti ad /MYSITE_NET;
3. aprire l'ambiente di sviluppo .NET e creare un nuovo progetto Web vuoto (es. /MYSITE_NET/myPrjNet.vbproj) nella directory /MYSITE_NET, dopodiché aggiungere a questo i file .asp del nostro sito (dal box "Soluzioni" click col tasto destro del mouse su myPrjNet.vbp e scegliere "Aggiungi elemento esistente": si aprirà la finestra per selezionare i file; per visualizzare gli ASP selezionare il filtro "File Web") puntata già sulla directory di lavoro.

Impostiamo, prima di tutto, un file di default (ovvero il primo file che verrà eseguito): lo selezioniamo dal box "Soluzioni", click col tasto destro del mouse "Imposta come Default".
Sia ad esempio /MYSITE_NET/default.asp; a questo punto potremmo già eseguire la nostra applicazione: infatti, se avviamo con CTRL+F5 e se il browser è in modalità "In linea" (se non lo fosse, accertarsi che il PWS sia avviato e poi da Explorer -> Menu File -> In Linea), tutto dovrebbe funzionare come sempre. Sorpresi?
ASP.NET è perfettamente compatibile con ASP e con esso può convivere benissimo, ma se per esperimento proviamo a rinominare un nostro file ASP con l'estensione ASPX le cose cambiano e non di poco.
Prima di fare tutto questo però passiamo ad un'altra meraviglia di questo ambiente di sviluppo: il Debugger.

Provate ad eseguire l'applicazione (dimenticavo, ogni tanto salvate!) in modalità 'Debug' (F5). Molto probabilmente riceverete un messaggio del tipo: "Per i progetti ASP.NET verificare che esista il file web.config per l'URL specificato e che l'opzione 'debug' sia impostata a TRUE in quel file; per ovviare a questo piccolo inconveniente procedere con Avvio -> Trova File -> web.config".
Insieme al vostro Framework questo file esiste già: non vi resta che farne una copia sulla vostra directory /MYSITE_NET/web.config e riprovare. Aprendo il file (XML) web.config con un editor di testo si scoprono altre cose interessanti, ma lascio al lettore la cura di analizzarlo.
Un altro modo per impostare il debug lato server di un singolo file ASP, ma non dell'intera applicazione, è quello di inserire come prima riga:

In questa riga di codice compare una delle nuove, fondamentali, direttive di ASP.NET: @Page, descritta nel paragrafo successivo.
Importante: l'esecuzione di applicazioni in modalità di debug causa un sovraccarico della memoria e una riduzione delle prestazioni. Assicurarsi che il debug di un'applicazione sia disattivato prima di distribuirla.

A questo punto possiamo provare a fare l'esperimento precedente; scegliamo un file asp in cui sia definito un <form> : converrà prima escluderlo dal progetto ([Gestione Soluzioni] -> myform.asp -> click col tasto destro del mouse -> "Escludi dal progetto") poi gli cambiamo l'estensione da .asp a .aspx e, quindi, lo riaggiungiamo al progetto.
Sicuramente otterrete un messaggio del tipo: "Il progetto non contiene un file di classe associato al web-form myform.aspx, crearne uno ora?”.
Ovviamente la vostra risposta non potrà che essere affermativa.
Il framework, a questo punto, farà due cose:
1) inserirà la seguente riga all'inizio di myform.aspx:

Questa direttiva al compilatore (le pagine ASP.NET non sono interpretate, ma compilate; la descrizione del processo di compilazione però esula dagli scopi di questo articolo, pertanto vi rimando alla documentazione ufficiale fornita dalla casa di Redmond o agli innumerevoli tutorial di cui sopra), che deve essere unica per ciascun file .aspx, informa quest'ultimo su molti parametri di compilazione.

2) Genererà il file myform.aspx.vb.
Effettivamente quello che faremo è spostare tutto (o quasi) il codice scritto nella pagina myform.asp originaria nel file myform.aspx.vb, in particolare tutte le Function e Sub definite nel .asp diverranno, dopo aver specificato il corretto modificatore di classe (Public, Protected o Private), i nostri metodi della classe.

Tutte le classi generate in questo modo derivano dalla classe padre system.web.ui.page e possiedono due metodi principali privati: Page_Init() e Page_Load(), il cui significato mi sembra evidente.
Maggiori dettagli sui parametri di tali metodi li lascio scoprire al lettore.

I principali sono:

1. [CodeBehind]: dove trovare il codice, ovvero la classe, che sta "dietro" la pagina .aspx, in questo caso nel file generato dal framework myform.aspx.vb;
2. [Language]: il linguaggio utilizzato: vb, C#, ecc.;
3. [Inherits]: la classe padre da cui eredita attributi e metodi (Public o Protected );
4. [Debug]: se eseguire o meno la pagina in modalità debug: True/False.

Questa opzione, come già accennato, non deve essere settata se si utilizza il file web.config per il progetto corrente.

A questo punto, dopo aver spostato tutti gli eventuali metodi nel file myform.aspx.vb (il codice "operativo", cioè quello inserito all'interno del BODY, della pagina .asp rimane nel .aspx), se riproviamo ad eseguire in modalità Debug scopriremo la potenza di quest'ultimo.
Alcuni degli errori più comuni nascono dalle novità di VB.NET, alcune delle quali sono:

1. tutte le variabili devono essere necessariamente dichiarate ed eventualmente tipizzate (il tipo Variant non esiste più, se non si specifica il tipo di default sarà: Object);
2. tutte le chiamate dei Metodi (Response.Write(), myRecordSet.Open(), ecc...) devono necessariamente essere dotate delle parentesi: non è possibile, ad esempio, scrivere Response.Write "Hello .NET!", ma si scriverà Response.Write("Hello .NET!");
3. le istruzioni Set e Let non sono più necessarie (tutto è ad oggetti!);
4. il costrutto: "While [...] Wend" diventa: "While [...] End While”.

Ovviamente non è necessario trasformare tutte le pagine .asp in aspx: infatti, come già detto, i due ambienti possono tranquillamente convivere.
Se però dichiariamo delle variabili di sessione in una pagina .aspx, questa non sarà visibile alle pagine .asp, pertanto sarà necessario convertire queste ultime in .aspx con il metodo descritto.

A questo punto vi chiederete: "Perché passare ad ASP.NET se la mia applicazione ASP funziona già a dovere?".
Le motivazioni principali che si possono trovare sono numerose: programmazione completamente Object Oriented (e quindi tutti gli innumerevoli vantaggi di quest'ultima: ereditarietà singola e multipla, polimorfismo, incapsulamento, maggiore manutenibilità, riutilizzo del codice); documentazione automatica da Reverse Enginering; per non parlare poi dell'ottimo e, secondo me, bellissimo Debugger; i controlli ASP.NET, di cui magari parlerò in un articolo successivo.


Si ringrazia Programmazione.it per la gentile concessione dell'articolo.