Quando si distribuiscono librerie sviluppate internamente nella propria organizzazione, indipendentemente dalla modalità di distribuzione scelta, le problematiche maggiori che si riscontrano sono due

• 1) Chi usa le librerie lamenta il problema di non poter debuggarne il sorgente, quando avviene una eccezione dentro la libreria non si riesce a capire cosa sia successo
• 2) Si perde traccia delle varie versioni e non si capisce quale progetto sia usando quale versione.

Mentre il punto due è stato già trattato in MSDN [Gestire la numerazione degli assembly Durante le build] il primo punto rimane spesso “parzialmente” irrisolto. Dico parzialmente perché spesso il sintomo è: Qualcuno riesce a debuggare i sorgenti mentre altri no. La ragione di questo è che nei file .pdb (i file dei simboli) ci sono scritte tutte le informazioni necessarie per debuggare, il problema è che il percorso dei file sorgenti è assoluto, e quindi se chi usa la libreria non ha i sorgenti nello stesso percorso locale di chi ha compilato la dll, quando si preme F11 (Step Into) per debuggare una funzione in una libreria, Visual Studio chiede dove trovare il file sorgente.

Anche se si adotta una policy per cui tutti gli sviluppatori tengono i sorgenti nello stesso percorso, questa soluzione non è corretta, dato che il sorgente presente nel disco è molto probabilmente l’ultima versione e quindi non è quasi mai lo stesso con cui è stata compilata la dll che si sta usando. Se consideriamo che potrebbero essere in circolazione più versioni di una certa dll, si può capire come sia impossibile adottare questo approccio.

La soluzione migliore è usare Team Foundation Server Build e specificare un proprio symbol server dove le build andranno a copiare le informazioni sui sorgenti, permettendo a chiunque abbia accesso al TFS ed alla libreria di simboli, di debuggare il codice delle dll prodotte dalle build. Questa soluzione è possibile sia per TFS on-premise, sia per TF Service, tutto quello che si richiede è che sia disponibile un Build Server che abbia accesso ad uno share di rete.

Dato che il TF Service fornisce supporto alla build con un servizio chiamato “elastic build” questa situazione non è verificata (il build server non accede a nessuno share di rete), per cui è necessario andare ad installare una macchina virtuale con un Build Controller on-premise oppure direttamente in Azure. In questo articolo vedremo la seconda strada, VM su Azure, ma si tenga in considerazione che la soluzione di avere una VM on-premise è completamente analoga.

Passo 1: installare e configurare il build agent

Dopo avere configurato una Virtual Machine in Azure (o on-premise) si dovrà procedere ad abilitare alcuni ruoli ed installare poi TFS Express:

• * –Abilitare il File Server role, per avere le share di rete
• * –Abilitare il Web Server per avere IIS e poter pubblicare un sito
• * –Istallare Team Foundation Server Express 2013 Update 3

A questo punto si può semplicemente creare una cartella per i simboli e creare uno share, in questo esempio l’indirizzo dello share è: \\tfssymbolserver\symbols

Figura 1: Creare uno share di rete configurato per lettura / scrittura

Ora non rimane altro da fare che configurare il build controller appena installato, le operazioni sono state già descritte per la versione beta di TFS 2012 nel mio blog su ugi [Installare un Build Server verso TF Service], al termine dell’installazione avrete il vostro build server funzionante.

Figura 2: Build controller and agent correctly configured for my TF Service account

Passo 2: Creare la build

Una volta che il Build Controller è operativo, si può procedere alla creazione di una definizione di Build per compilare la versione binaria della propria libreria che si vuole rilasciare. Le opzioni sono le solite, basta ricordare nella Build Default di scegliere il controller appena installato e non l’elastic build, in questo modo è possibile eseguire la build sulla Virtual Machine appena configurata.

Figura 3: Configure the build defaults

L’unica altra parte della configurazione peculiare a questo esempio è la configurazione del Symbol Server, in questo caso infatti si sceglierà il valore True per l’opzione “Index Sources” e si specificherà lo share di rete precedentemente creato. In questo caso l’agent ed il controller risiedono sulla stessa macchina e quindi non vi è nessun problema di accesso (Figura 4)

Se nel vostro scenario il server di build è on-premise è possibile scegliere una qualsiasi share di rete che sia accessibile dall’utente usato per eseguire il Build Agent .

Figura 4: Il tab del processo di build con evidenziato il template di versioning e le opzioni per la pubblicazione dei simboli.

L’altro aspetto interessante della build è l’uso del Versioning Build Template presente nella libreria TFS Versioning [http://tfsversioning.codeplex.com/], che permette di assegnare un FileVersionAttribute univoco ad ogni dll, dal quale è possibile risalire quindi alla build che lo ha generato.

Ora che tutto è configurato è possibile lanciare la build ed al termine verificare che la cartella dei simboli contenga le cartelle dei simboli, questo significa che la pubblicazione dei simboli è andata a buon fine..

Figura 5: Symbols files are correctly published in the local share

Passo 3: pubblicare la libreria dei simboli con IIS

Se il vostro build server è on-premise, non si deve fare altro, perché la share di rete che contiene il symbol server sarà visibile a tutti i computer della rete. In caso di VM su Azure invece è necessario trovare una tecnica alternativa allo share di rete per permettere ai computer client di accedere alla libreria dei simboli.

La soluzione più semplice è quella di usare IIS e pubblicare un sito che punti allo share di rete, con abilitato la Directory Browsing. Alternativamente è possibile anche impostare una VPN tra la VM in azure e la propria rete locale, ma la soluzione con IIIS è di gran lunga la più semplice e veloce da impostare.

Figura 6: Symbol server is now publishing the symbol directory to the web with IIS

Nel mio esempio ho scelto la porta 27000 per la pubblicazione, ricordate comunque che affinché il sito sia visibile dall’esterno è necessario aprire la porta scelta nel firewall interno di windows, e creare un endpoints nel pannello di controllo azure relativo alla vostra Virtual Machine

Figura 7: Creazione dell’endpoint per esporre all’esterno la porta 27000

Una volta che è stato creato l’endpoint si dovrebbe essere in grado di navigare all’indirizzo scelto e vedere i file dai computer della vostra rete.

Figura 8: Il symbol server è ora esposto in HTTP

Passo 4: Configurare il Visual Studio per usare la libreria dei simboli

L’ultimo passo è configurare il Visual Studio dei programmatori che andranno ad utilizzare la libreria, specificando nelle opzioni (Tools->Options) nella sezione Debugger, l’indirizzo del server dei simboli. Nella figura sottostante è possibile vedere anche configurata una share di rete locale, nel caso che il Build Server sia stato configurato on-premise.

Figure 9: Il symbol server è ora stato configurato in visual studio

Non bisogna inoltre dimenticare di abilitare il Source Server support, altrimenti i vari Symbol server verranno ignorati.

Figure 10: Configurazione generale del debugging per abilitare l’uso dei symbol server

Giunti a questo punto, indipendentemente dal modo scelto per distribuire la propria libreria, l’importante è prelevare i binari dalla drop folder della build e naturalmente ricordare di distribuire non solamente le dll, ma anche i vari .pdb generati dalla build.

Figure 11: La versione compilata della libreria può essere ora scaricata direttamente dalla drop folder della build

In questo caso i file dei simboli generati dalla build, contengono un riferimento al TFS da cui sono stati presi i sorgenti. Basta quindi referenziare la dll nel proprio progetto e durante il debug, se si preme F11 da Visual Studio, è possibile senza alcun problema andare a debuggare i sorgenti, che vengono scaricati automaticamente dal vostro TFS (Dovete chiaramente essere loggati ed avere accesso al tfs per poter visualizzare il sorgente).

Figure 12: Premendo F11 si è in grado di entrare in debug nei file sorgenti usati per la compilazione della dll

Quello che accade è, una volta premuto F11, Visual Studio legge dal file .pdb la posizione del codice sorgente relativo all’istruzione attuale, contatta la libreria dei simboli e TFS, scaricando cosi la versione corretta del file. Se si osserva con attenzione il nome del file in Figura 12 si può notare come prima del nome del file (myLogLibrary.cs) sia presente un numero (1046), che altro non è che il changeset id.

Figure 13: L’ultima modifica fatta al file è appunto la versione 1046

L’aspetto interessante dell’avere messo in opera un symbol server non è solamente l’abilità di poter effettuare il debug di qualsiasi libreria interna senza doversi preoccupare di dove sia il sorgente, ma anche il fatto di poter effettuare il debug avendo sempre a disposizione la versione esatta del sorgente utilizzato per compilare la dll che si sta usando

Infine si ricordi che è comunque possibile risalire alla build utilizzata semplicemente dalle proprietà del file, grazie alla libreria di versioning.

Figure 14: Il numero di versione identifica esattamente la build utilizzata per compilare la dll

NOTA BENE: I simboli pubblicati sono parte della build, per cui è necessario ricordare di non cancellare mai le build usate per pubblicare i simboli, o se le si cancella di non cancellare i relativi simboli, altrimenti tutte le dll che avete distribuito relative a quella build, non saranno più in grado di riconnettersi ai rispettivi sorgenti

Figura 15: Non cancellare mai i simboli di una libreria pubblicata, oppure non si sarà più in grado di effettuare il debug.

Una buona norma è marcare con Retain Indefinitely tutte le build relative a versioni pubblicate e disabilitare comunque la cancellazione automatica dei simboli per le build.

Figura 16: Anche se si richiede di tenere solamente le ultime 10 build riuscite, si può scegliere di non cancellare mai i relativi simboli pubblicati

Gian Maria.