Controlli in bin o esegui il debug di cartelle (e dll) nel tuo TFS?

Come regola generale, il controllo del codice sorgente viene utilizzato al meglio solo per l'origine e i file generati non sono sorgente.

Ci sono delle eccezioni. A volte (usando Visual Studio) potresti voler mantenere il file .pdb per leggere i minidump. A volte non è possibile duplicare una toolchain, in modo che non sia possibile ricreare con precisione i file generati. In questi casi, sei principalmente interessato a farlo per il software rilasciato, non per ogni modifica VCS, e in ogni caso questi possono risiedere facilmente nelle cartelle con versione. (Questi sono in genere file binari, comunque, e non hanno cambiamenti comprensibili da una versione all'altra, e non traggono molto beneficio dall'essere in un VCS.)

Risposta semplice? No. Non farlo! Non riesco a pensare a molte ragioni per non farlo, ma non c'è motivo per cui tu voglia.

L'unica volta che posso pensare di controllare una dll è se proviene da una libreria di terze parti che non ti aspetti che ogni sviluppatore abbia installato per la compilazione. Ma anche in questo caso, non si trova nella cartella bin.

Detto questo, ho lavorato in una società che richiedeva che ogni pacchetto di implementazione fosse messo in controllo del codice sorgente, ma era così che potevamo tenere traccia delle varie build che avevamo dato al nostro cliente e potevamo facilmente tornare indietro se necessario.

Non controlliamo la cartella bin in TFS. Come probabilmente avrai notato, se lo fai, ogni volta che uno sviluppatore crea la soluzione, controllerà la cartella bin. Non bene. Tuttavia ci sono librerie che il progetto ha bisogno per compilare ed eseguire, e la nostra regola è che qualsiasi progetto dovrebbe poter essere aperto dal controllo del codice sorgente, e dovrebbe compilare ed eseguire. Quindi, ciò che facciamo è creare una cartella "BinRef" per qualsiasi DLL a cui il progetto deve fare riferimento e creare i riferimenti del progetto alla copia nella cartella BinRef. La cartella BinRef è archiviata in TFS.

L'altro vantaggio di questo approccio è che BinRef è sempre al livello principale del progetto web. Se il mio progetto vive in C:\Projects\Marcie\SomeProjectCategory\ProjectA e creo un riferimento a una DLL che si trova in C:\DLLsThatILike , il riferimento avrà un aspetto simile a

\..\..\..\NiceThing.dll

. Puoi conservare i file di progetto in C:\ProjectA , il che significa che il riferimento al progetto su NiceThing esploderà sul tuo computer. Spero che le persone non stiano facendo riferimenti in questo modo, ma l'ho visto accadere.

Effettuiamo il check-in del contenuto delle directory del cestino come parte del nostro processo di richiesta di modifica. Per evitare problemi di sola lettura, copiamo i contenuti in una cartella separata e li controlliamo da lì. La nostra politica aziendale richiede che tutti i file binari che vanno in produzione siano archiviati separatamente dalla fonte. Non è la soluzione migliore ma funziona e ci fornisce i file esatti che sono in produzione.

Esito a controllare qualsiasi file non di testo nel controllo del codice sorgente. Soprattutto quelli che dovrebbero essere generati dallo sviluppatore. Mi piace anche tenere altri file binari, come immagini e PDF, compressi e archiviati altrove per ogni tag / release.

No, ma il nostro strumento di controllo del progetto interno lo fa automaticamente, il che mi infastidisce.

La mia soluzione è quella di contrassegnare tutti i file in versione ed eseguire il debug come scrivibili e quando TFS si lamenta, dico di ignorare i file, quindi non ho mai avuto problemi con un errore di compilazione.

Evito di inserirli nel controllo del codice sorgente. Sono informazioni ridondanti, i binari possono essere creati dal codice sorgente in quella revisione. Inoltre, il codice sorgente è sempre aggiornato, le build potrebbero non essere in corso.

Salviamo alcuni file binari generati, come gli interrupt .NET da un altro progetto. Quindi, se ho un progetto A che crea un oggetto COM, e quindi usi quell'oggetto COM in un progetto B molto approssimativo che lo usa tramite .NET interop, controllo l'interp generato dal progetto A nel progetto B. Non è una buona idea, ma deve andare da qualche parte perché AFAIK Visual Studio non creerà l'interoperabilità per il tuo automaticamente durante la compilazione.

Secondo me, non memorizzare i binari nel controllo del codice sorgente è uno degli errori più comuni. Dovrebbero essere archiviati, versionati, baselined / etichettati insieme ai sorgenti e anche strumenti di compilazione. Crea te stesso con la creazione di software non tracciabile ...