Tutti noi conosciamo l’importanza dei files di codice sorgente. Abbiamo per questo il source control. Ma…non c’è solo questo. Infatti un’altra serie di oggetti fondamentali spesso sono ignorati: i file PDB (Program Database).

Innanzitutto, cosa sono. Sono dei file al cui interno sono specificati (per un .pdb .NET) i nomi dei file di codice sorgente ed I nomi delle variabili. Questi file sono i simboli del nostro codice sorgente, rendendo possibile operazioni come il debug.

Come fa Visual Studio a capire quali simboli sono legati alla versione attuale del nostro codice sorgente? All’interno del PDB è memorizzato un GUID che identifica ogni versione.

Non sono file da distribuire, ma da tenere a disposizione per ogni evenienza di debug e non solo (ad esempio, IntelliTrace si basa pesantemente sui PDB).

Cosa serve per mantenere i PDB disponibili? Un Symbol Server, ossia un server (con una share di rete sostanzialmente) dove copiare i file una volta terminata la compilazione. Team Build permette di copiare direttamente i file PDB “da qualche parte” già con il Process Template di default, per cui siamo a posto

Ne approfitto per segnalare un *fantastico* articolo di Ed Blankenship (Visual Studio ALM MVP) che ci spiega come creare un Symbol Server e come impostare il supporto al SS da Visual Studio 2010.

Una delle novità di Visual Studio che è passata parecchio in sordina è quella dei Data-tier Application Project: vediamo di che si tratta.

Solitamente nelle aziende ci si scontra con un grande problema: gestire il deploy del database in produzione. Inoltre, ora che abbiamo anche il fattore SQL Azure da considerare, c’è una variabile in più in gioco.

La soluzione al problema (per chi usa SQL Server 2008 R2 e/o SQL Azure) si chiama per l’appunto Data-tier Application Project.

Consiste di un “pacchetto” che contiene tutte le informazioni sul nostro database, dalla Collation fino alle impostazioni di sicurezza (oltre a tabelle, stored procedure, ecc.). Con un clic scegliamo se effettuare il deploy su un nostro database, oppure su Azure. Unica nota: al momento solo SQL Server 2008 R2 ha il supporto a questa funzionalità.

Partendo da SQL Server Management Studio, posso creare un Data-tier Application Package nello stesso modo di Visual Studio, partendo magari da un database esistente.

Questo è secondo me uno strumento interessantissimo nel caso in cui si debbano mantenere database sia su Azure che in casa