Migrare dalla vecchia versione di Lightswitch a quella nuova

Mi spiego meglio. Quella vecchia è quella usabile da Visual Studio 2010, la versione 1.0. Quella nuova è quella integrata in Visual Studio 2012.

In Brain-Sys abbiamo sviluppato un gestionale per un nostro cliente, proprio con la versione 1.0 di Lightswitch. Inutile dire che lo sviluppo è stato estremamente rapido, ed il deploy altrettanto. Seguire le continue richieste del cliente (compreso qualche leggero bug-fixing) è sempre un’operazione piuttosto semplice, compreso aggiornare l’applicazione sul server di produzione. Penso che Lightswitch sia lo strumento di sviluppo più RAD che abbia mai visto, dai tempi di…Access. Eppure le differenze con Access ci sono eccome, perchè in realtà l’interfaccia utente dell’applicazione web (che gira in browser in un’applicazione Silverlight) comunica con il database attraverso un servizio WCF, mettendo così in piedi – in modo totalmente automatico – un’applicazione three-tier. Ovvio che il servizio WCF è consumabile anche da app di altra natura (è un servizio esposto via http), come Windows Phone o Windows 8, e quindi…lascio immaginare a voi quali sono le piacevoli conseguenze di tutto questo.

Ma torniamo a noi.

In questi giorni ho dovuto affrontare un problema che magari potrebbe capitare anche a voi. Lo scenario è il seguente: supponiamo di aver sviluppato e messo online, un anno fa, un’applicazione Lightswitch 1.0, che il cliente ha cominciato ad usare con successo, riempiendo il database con anagrafiche, fatture, eccetera eccetera. Dopo un anno, oggi appunto, il cliente vi chiede una piccola modifica. Peccato che l’applicazione venne creata e compilata con VS2010, mentre oggi voi volete gestire il tutto con VS2012. Perchè? Per una serie di motivi, il più importante dei quali si può riassumere nella seguente frase.

In Brain-Sys crediamo fermamente che sia importante utilizzare gli strumenti di sviluppo più recenti, per non rimanere tagliati fuori, per usare sempre l’ultimo .NET Framework disponibile. Se si aspetta troppo, se si perde l’onda, se si lasciano “decantare” troppo le tecnologie, esse finiranno per diventare obsolete. Ed arriverà il momento in cui sarà troppo tardi, e magari dovremo ricreare l’applicazione da zero. Chiaramente questa filosofia si scontra con la pratica, con il web-server a disposizione, con le richieste del cliente, con vincoli e requisiti entro i quali dobbiamo stare. Ma facciamo di tutto per farcela, insomma.

Beh, insomma, come ho risolto la migrazione dell’applicazione Lightswitch 1.0 alla 2.0, senza perdere i dati del cliente, e facendo in modo che per lui sia stato tutto trasparente? Ecco una piccola scaletta.

1. Backup dell’applicazione attuale (database SQL Server e file system)
2. Conversione dell’applicazione Lightswitch 1.0 con Visual Studio 2012
3. Deploy dell’applicazione sul vostro IIS locale
4. Restore in locale del database del cliente e aggiornamento schema
5. Test in locale dell’applicazione
6. Messa in produzione della nuova applicazione

Dettagli punto (1)
In breve: ho un bel folder sul proprio PC con il .bak del database SQL Server corrente (pieno di dati dell’utente) e tutti i files che compongono l’applicazione (xap, dll, web.config e via dicendo). Ovviamente tutto questo è l’applicazione alla versione 1.0 di Lightswitch. Così in caso di problemi potremo tornare indietro senza troppi danni.

Dettagli punto (2)
Nulla di particolarmente complicato, in apparenza. Aprite la solution con VS2012: lui si accorgerà che l’applicazione è stata creata con una versione precedente di Lightswitch e vi proporrà la conversione. Accettate e siete a posto. Attenzione: assicuratevi di aver installato le stesse extension Lightswitch che avevate usato all’epoca, ed assicuratevi inoltre che esse siano compatibili con VS2012. Se tutto va bene, riuscirete a compilare e ad eseguire l’applicazione da Visual Studio con un semplice F5. Se questo avviene, siete già a buon punto, perchè forse è la parte più critica.

Dettagli punto (3)
Io mi sono trovato comodo così, ovvero: ho installato IIS sul mio PC locale, e da Visual Studio 2012 ho deployato l’applicazione Lightswitch in locale, quindi ad un url tipo http://localhost/mia_applicazione. Ricordo che Visual Studio deve essere avviato come Administrator. Il wizard si occuperà di chiedervi tutte le informazioni necessarie, compreso il database da utilizzare. Io ho utilizzato l’istanza di SQL Server Express locale, fornendo le connection string di un database completamente vuoto. Il wizard crea lo schema del database. Fatto questo, potete aprire un browser, navigare all’url, avviare ed usare l’applicazione Lightswitch installata localmente sul vostro PC. Chiaramente il database sottostante è completamente vuoto, perchè è stato appena creato ex-novo da Visual Studio. E’ ora di importare i dati del cliente!

Dettagli punto (4)
Ok, allora. Prendete il .bak di cui avete fatto il backup al punto (1) e restoratelo sul database che avete creato al punto (3). Attenzione, però. C’è una piccola ma grande differenza tra una tabella creata da Lightswitch 1.0 e da Lightswitch 2.0. Ogni tabella contiene un campo RowVersion di tipo timestamp. Quindi, per esempio, se nella vostra applicazione Lightswitch 1.0 avevate un’entità Person, con Surname e Name, la tabella conterrà i campi ID, Surname, Name. La stessa entità creata con Lightswitch 2.0, oltre a questi campi, ha anche RowVersion.

Quindi, facciamo mente locale. L’applicazione Lightswitch deployata sul vostro IIS è alla versione 2.0, quindi si aspetta che tutte le tabelle abbiano questo famigerato campo RowVersion. Ma il database che abbiamo appena restorato ha uno schema che fa riferimento a Lightswitch 1.0, per cui quello che dobbiamo fare è banalmente andare ad aggiungere il campo con una semplice ALTER TABLE:

ALTER TABLE [dbo].[NomeTabella]
ADD [RowVersion] [timestamp] NOT NULL
GO

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Io ho creato uno script che fa questa semplice operazione su tutte le tabelle che compongono la mia applicazione. Ho preferito uno script perchè verrà molto, molto comodo quando sarà il momento di mettere on-line la nuova applicazione Lightswitch, perchè basterà eseguirlo per aggiornare il database.

Dettagli punto (5)

Fatto questo, siete a posto. Avete migrato l’applicazione da Lightswitch 1.0 a Lightswitch 2.0, con tutti i vantaggi del caso, e senza perdere alcun dato inserito dal nostro cliente. Provate l’applicazione in locale, fate tutte le prove possibili ed immaginabili. Tanto state usando un database locale, sul vostro PC, perciò niente danni per il cliente, no? Se siete soddisfatti, potete mettere tutto on-line davvero.

Dettagli punto (6)

Ok, come si aggiorna l’applicazione Lightswitch sul server di produzione? Come qualsiasi altra applicazione .NET, ovvero: aggiornando un po’ di files sul server, magari trasferendoli via ftp. Io di solito sto molto attento a questo. Non faccio un “seleziona tutto”, “trasferisci”. Copio le dll, il nuovo xap, etc. etc. Evito il web.config (che magari contiene qualche configurazione particolare, soprattutto le connection string). Prima di provare l’applicazione, ricordatevi il database. Eseguite lo script con le ALTER TABLE sul database di produzione, che andrà ad aggiungere il campo RowVersion su tutte le tabelle: esattamente ciò che avete fatto prima sul vostro database locale.

Un’ultima osservazione 

Ho notato una cosa strana. La nostra applicazione chiede un login, all’avvio. Con Lightswitch 1.0, la pagina Silverlight che permette il login è piuttosto spartana. C’è una casella per l’inserimento del nome-utente, una per la password ed un bottone Accedi. Basta. Niente loghi, niente immagini. Essenziale, diciamo. Una volta migrata l’applicazione in Lightswitch 2.0, questa pagina è cambiata, ed a me appariva un enorme rettangolone giallo, che proprio non ho capito da dove arrivasse. Praticamente occupava il 90% della pagina, giusto sopra le due caselle sopra citate. Alla fine ho capito. Sono andato nelle proprietà del progetto Lightswitch, sotto “General Properties”, e qui c’è una voce “Logo image”, che puntava ad un file “ResourcesBackground.png”. E guarda caso questa immagine .png era proprio un rettangolo giallo. Ho sostituito questa png con qualcosa di più gradevole (ad esempio…il logo dell’applicazione, il logo dell’azienda del cliente) et voilà: a questo punto la pagina di login non mostra più il rettangolo giallo di prima, ma la nuova immagine che abbiamo impostato.

Direi che la missione è compiuta!!