Con la doverosa premessa che la paternità di questo post va condivisa con il buon Janky.
Visual Studio .NET 2003 (credo anche 2002, ma, grazie a Dio, non devo pormi questa domanda) ha un comportamento che potrebbe sembrare piuttosto strano rispetto l'interazione tra i progetti Web e il Source Control.
Avete mai provato a scaricare per la prima volta una Web application .NET 1.1 da Team Foundation Server e successivamente aprirla con Visual Studio? Quasi sicuramente vi sarà comparsa una schermata che vi propone di creare il binding tra il vostro codice sorgente ed il famigerato progetto web (che non viene trovato!).
Nulla di buono viene dopo questa schermata (annulla vi salta il caricamento del progetto Web in questione, ok vi porta ad una schermata di richiesta di creazione di un binding all'interno di un workspace, che si rileva impossibile da creare).
Tutto questo, in buona sostanza, succede per due motivi:
- VS2003 memorizza la locazione dei progetti Web in base alla loro posizione nel web stesso (quindi http://localhost/VirtualDirectory se sviluppate in una macchina locale), mentre il Source Control li memorizza in base alla struttura logica della solution (quindi la cartella Web sotto a quella della solution).
- Le solution sono accompagnate da un file ".suo" che contiene le "user options" della solution. Questo, ovviamente, non viene inserito nel Source Control in quanto varia da utente a utente, ma contiene le informazioni mancanti per il binding tra TFS e progetto Web
La procedura da adottare (la cui paternità é, appunto, di Janky) per ricostruire il binding in maniera corretta é:
- Ceare la cartella che conterrà il progetto Web e impostarla come Virtual Directory
- Aprire VS 2003, Menù File, Source Control, Open from Source Control e infine selezionare server e percorso della solution
Fin qui tutto bene, ma supponiamo ora che voi dobbiate scaricare su un computer qualche centinaio di applicazioni. Ho cercato di trovare qualche soluzione, ma non tutte si sono rivelate praticabili:
- Creare da codice i file .suo con il binding corretto
- Usare il Visual Studio SDK per automatizzare l'apertura
- Scaricare i sorgenti e rimuoverne il collegamento con il Source Control da codice
- Prendere un dipendente-scimmietta (offesa riferita al lavoro non al dipendente) che faccia il lavoro a mano al posto vostro
Dicevo che non tutte le strade sono praticabili:
- I file suo, a differenza di sln e ((cs)|(vb))proj sono in formato proprietario binario. Non sono riuscito a trovare documentazione su come crearli/modificarli
- Il comando File.OpenFromSourceControl da invocare con: EnvDTE.ExecuteCommand("File.OpenFromSourceControl") sembra non accettare alcun parametro (e manca completamente documentazione ufficiale in merito)
- Io ho deciso di praticare questa via perché ai miei fini non era importante che il codice rimanesse collegato al Source Control (non veniva modificato, ma solo analizzato). Nella parte 2 vi do le dritte necessarie.
- Beh... Questa é la soluzione che ho visto praticare più spesso... Per altro vi consiglio di procurarvi quantomeno una persona socievole e piacevole d'aspetto altrimenti impazzirete a sentire i suoi sbuffi dopo la prima giornata!