TFS 2008, rimuovere il file dal controllo del codice sorgente ma lasciarlo nel progetto

Question

Stiamo utilizzando il suggerimento di Scott Hansleman per più web.configs dal suo post here. Il problema è che dobbiamo controllare Web.Config. Se lo rimuoviamo dal progetto, quando pubblichiamo, non viene inviato alcun web.config. Quindi dobbiamo rimuovere i binding del controllo sorgente solo da web.config, ma lasciarlo nel progetto e mantenere il resto del progetto ancora sotto il controllo del codice sorgente.

Il problema è che il controllo del codice fa sì che il file venga letto solo fino a quando non lo si controlla. Dobbiamo essere in grado di sovrascriverlo con gli eventi di pre-costruzione, preferibilmente senza doverlo verificare. C'è un modo per rimuovere solo i binding da quel file e lasciarlo come parte del progetto?

Grazie.

Answer 1

Aggiungendo un nuovo file a solution explorer, si otterrà il piccolo segno più che indica che sarà aggiunto al controllo del codice sorgente. Quindi, fai clic con il tasto destro e scegli "annulla modifiche in sospeso". Questo annullerà l'add, ma lascerà il file nel tuo progetto.

Se questo non funziona Suggerisco uno dei seguenti metodi:

• utilizzare l'attività Attrib dal progetto MSBuild Community Tasks per rimuovere la lettura unica bandiera.
• Utilizzare lo Exec task in MSBuild per richiamare tf.exe e verificare il file.

Answer 2

È necessario lasciare il file nel controllo sorgente. In caso contrario, si verificheranno diversi problemi:

• le modifiche non saranno versioni. 'ha detto nuf.
• non può essere ramificato o unito, anche se web.config è uno dei file che è più probabile che vari tra gli ambienti di sviluppo/test/produzione paralleli
• le modifiche apportate localmente non si propagheranno ai colleghi senza manuale soluzioni alternative
• gli sviluppatori che impostano un ambiente per la prima volta non otterranno affatto il file
• Team Builds non conterrà il file, quindi nemmeno le vostre distribuzioni. (sicuramente non stai distribuendo direttamente dal desktop ?!)

Si noti che lo stato dei singoli file è memorizzato interamente sul server TFS. ('tf properties' scarica questi metadati se siete curiosi) Solo le soluzioni di progetto & contengono effettivamente dei bind scritti nel file. E anche quelli sono voci fittizie che dicono a VS "non preoccuparti per me, basta chiedere a TFSProvider, saprà chi sono e dove dovrei essere". Mentre ci sono molte altre stranezze nel sistema di progetto VS che mi danno mal di testa senza fine, in questo caso è tuo amico. Non eluderlo.

migliori opzioni:

1. modificare il proprio script di build per attivare o disattivare l'attributo di sola lettura la modifica prima/dopo. Se stai usando lo script "copyifnewer.bat" dal post del blog collegato, dovrebbe essere letteralmente una riga in più. Anche se si desidera mantenere le cose interamente dichiarative all'interno del makefile MSBuild, è praticamente impossibile lavorare con l'aiuto di 3rd party tasks.

2. Utilizzare il comando File -> Controllo origine -> Escludi. Dopo aver applicato questa impostazione, il file rimane sotto il controllo del codice sorgente, ma non sarà più soggetto a checkout/checkout automatici dalla soluzione attiva. In altre parole, puoi modificare il file localmente in base al contenuto del tuo cuore senza influire su nessun altro, ma se vuoi impegnare (o accantonare) le tue modifiche, dovrai farlo da Source Control Explorer o dalla riga di comando.

L'opzione n. 1 ha il vantaggio di essere una soluzione molto rapida per la configurazione esistente. Il rovescio della medaglia deriva dal mantenimento di diverse copie di web.config. * Lo stesso motivo per cui il codice copia/incolla è sbagliato: se ne modifichi uno, devi cambiare tutti gli altri - o peggio, dimenticarli e lasciarli andare alla deriva fino alla sincronizzazione strani bug ti costringono a rivisitare il problema. Questo potrebbe essere migliorato cambiando il processo in modo che ci sia solo 1 "master" web.config e le copie aggiuntive contengano solo differenze (tramite un motore di confronto testuale, trasformazioni XSLT, manipolazione programmatica in Powershell, ecc.). Certo, è più lavoro.

L'opzione n. 2 evita i problemi del primo con pochissimo overhead. (lo stesso processo di progettazione è invariato, solo la differenza è come si comporta l'interfaccia utente di Visual Studio) Questo vantaggio è fondamentale se si apportano modifiche a web.config con frequenza frequente. Il lato negativo è che non esiste un modo integrato per tenere traccia delle variazioni sul file "master". Se le uniche differenze sono semplici, ad esempio una o due stringhe di connessione, potresti trovare più facile attaccare con un solo "master" e consentire alle persone di apportare modifiche ad hoc sulle loro macchine dev. Esistono anche strumenti per farlo, come ad esempio Web Deployment Projects (facile) e lo IIS Deployment Tool (complesso). In ogni caso, la tua implementazione effettiva dovrebbe essere automatizzata e controllata dalla fonte, ovviamente! Se sono necessarie personalizzazioni più pesanti di quelle che sono in grado di questi strumenti, probabilmente si vorrà che l'approccio di master + trasformatore ibrido sia descritto in precedenza.