È necessario eseguire il commit di un .sln nel controllo del codice sorgente?

È consigliabile eseguire il commit di un file .sln nel controllo del codice sorgente? Quando è appropriato o inappropriato farlo?

Aggiornamento Ci sono stati molti punti positivi nelle risposte. Grazie per le risposte!

Penso che sia chiaro dalle altre risposte che i file della soluzione sono utili e dovrebbero essere impegnati, anche se non sono usati per build ufficiali. Sono utili per chiunque utilizzi funzionalità di Visual Studio come Vai a definizione / dichiarazione.

Per impostazione predefinita, non contengono percorsi assoluti o altri artefatti specifici della macchina. (Sfortunatamente, alcuni strumenti aggiuntivi non mantengono correttamente questa proprietà, ad esempio AMD CodeAnalyst.) Se stai attento a utilizzare percorsi relativi nei tuoi file di progetto (sia C ++ che C #), saranno indipendenti dalla macchina pure.

Probabilmente la domanda più utile è: quali file dovresti escludere? Ecco il contenuto del mio file .gitignore per i miei progetti VS 2008:

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

(L'ultima voce è solo per il profiler AMD CodeAnalyst.)

Per VS 2010, dovresti anche escludere quanto segue:

ipch/
*.sdf
*.opensdf

Sì, penso sia sempre appropriato. Le impostazioni specifiche dell'utente si trovano in altri file.

Sì, dovresti farlo. Un file di soluzione contiene solo informazioni sulla struttura complessiva della soluzione. Le informazioni sono globali per la soluzione ed è probabile che siano comuni a tutti gli sviluppatori del progetto.

Non contiene impostazioni specifiche dell'utente.

Dovresti assolutamente averlo. Oltre alle ragioni menzionate da altre persone, è necessario rendere possibile la costruzione in un unico passaggio dell'intero progetto.

In genere sono d'accordo sul fatto che i file della soluzione debbano essere archiviati, tuttavia, presso l'azienda per cui lavoro abbiamo fatto qualcosa di diverso. Abbiamo un repository abbastanza grande e gli sviluppatori lavorano di tanto in tanto su parti diverse del sistema. Per supportare il modo in cui lavoriamo avremmo un unico file di soluzione grande o diversi file più piccoli. Entrambi hanno alcuni difetti e richiedono un lavoro manuale da parte degli sviluppatori. Per evitare ciò, abbiamo creato un plug-in che gestisce tutto ciò.

Il plug-in consente a ogni sviluppatore di estrarre un sottoinsieme dell'albero dei sorgenti su cui lavorare semplicemente selezionando i progetti rilevanti dal repository. Il plugin quindi genera un file di soluzione e modifica al volo i file di progetto per la soluzione data. Gestisce anche i riferimenti. In altre parole, tutto ciò che lo sviluppatore deve fare è selezionare i progetti appropriati e quindi i file necessari vengono generati / modificati. Questo ci consente anche di personalizzare varie altre impostazioni per garantire gli standard aziendali.

Inoltre, utilizziamo il plug-in per supportare varie politiche di check-in, che generalmente impediscono agli utenti di inviare codice difettoso / non conforme al repository.

Sì, le cose che dovresti impegnarti sono:

• soluzione (* .sln),
• file di progetto,
• tutti i file sorgente,
• file di configurazione dell'app
• costruire script

Le cose che non dovresti impegnare sono:

• file delle opzioni utente della soluzione (.suo),
• compilare i file generati (ad esempio utilizzando uno script di compilazione) [Modifica:] - solo se tutti gli script e gli strumenti di compilazione necessari sono disponibili sotto il controllo della versione (per garantire che le compilazioni siano autentiche nella cronologia di cvs)

Per quanto riguarda altri file generati automaticamente, c'è un thread separato .

Sì, dovrebbe far parte del controllo del codice sorgente. Ogni volta che aggiungi / rimuovi progetti dalla tua applicazione, .sln viene aggiornato e sarebbe bene averlo sotto il controllo del codice sorgente. Ti consentirebbe di estrarre le versioni del codice dell'applicazione 2 indietro e di eseguire direttamente una build (se necessario).

Nella maggior parte dei casi, è una buona idea eseguire il commit dei file .sln nel controllo del codice sorgente.

Se i tuoi file .sln sono generati da un altro strumento (come CMake), probabilmente è inappropriato metterli nel controllo del codice sorgente.

Sì, vuoi sempre includere il file .sln, include i collegamenti a tutti i progetti che sono nella soluzione.

Lo facciamo perché mantiene tutto sincronizzato. Tutti i progetti necessari si trovano insieme e nessuno deve preoccuparsi di perderne uno. Il nostro server di compilazione (Ant Hill Pro) utilizza anche sln per capire quali progetti costruire per una versione.

Di solito mettiamo tutti i nostri file di soluzioni in una directory di soluzioni. In questo modo separiamo un po 'la soluzione dal codice ed è più facile scegliere il progetto su cui devo lavorare.

L'unico caso in cui potresti anche considerare di non memorizzarlo nel controllo del codice sorgente sarebbe se avessi una grande soluzione con molti progetti che era nel controllo del codice sorgente e volessi creare una piccola soluzione con alcuni dei progetti dalla soluzione principale per alcuni requisito transitorio privato.

Sì, tutto ciò che viene utilizzato per generare il prodotto dovrebbe essere nel controllo del codice sorgente.

Conserviamo o risolviamo i file in TFS Version Control. Ma poiché la soluzione principale o è davvero grande, la maggior parte degli sviluppatori ha una soluzione personale contenente solo ciò di cui hanno bisogno. Il file della soluzione principale viene utilizzato principalmente dal server di compilazione.

.slns sono l'unica cosa con cui non abbiamo avuto problemi in tfs!