Un .sln dovrebbe essere impegnato nel controllo del codice sorgente?

https://stackoverflow.com/questions/1033809

06-07-2019
|

Domanda

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

Aggiorna Ci sono stati diversi punti positivi nelle risposte. Grazie per le risposte!

Soluzione

Penso che sia chiaro dalle altre risposte che i file di soluzione sono utili e dovrebbero essere impegnati, anche se non sono usati per build ufficiali. Sono utili per chiunque utilizzi le 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 usare percorsi relativi nei tuoi file di progetto (sia C ++ che C #), saranno indipendenti dalla macchina anche.

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

Altri suggerimenti

Sì, penso che 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 generale della soluzione. Le informazioni sono globali per la soluzione ed è probabilmente comune a tutti gli sviluppatori del progetto.

Non contiene alcuna impostazione specifica dell'utente.

Dovresti assolutamente averlo. Oltre alle ragioni menzionate da altre persone, è necessario rendere possibile un passo di costruzione di tutti i progetti

Sono generalmente 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 archivio abbastanza grande e gli sviluppatori lavorano di volta in volta su diverse parti del sistema. Per supportare il nostro modo di lavorare avremmo o un file di soluzione grande o più piccoli. Entrambi presentano alcune carenze 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 ciascuno sviluppatore di verificare un sottoinsieme dell'albero di origine su cui lavorare semplicemente selezionando i progetti rilevanti dal repository. Il plug-in genera quindi un file di soluzione e modifica i file di progetto al volo per la soluzione fornita. 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 al repository codice difettoso / non conforme.

Sì, le cose che dovresti commettere sono:

soluzione (* .sln),
file di progetto,
tutti i file di origine,
file di configurazione app
crea script

Le cose che dovresti non commettere sono:

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

Per quanto riguarda altri file generati automaticamente, esiste un thread separato .

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

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

Nella maggior parte dei casi, è una buona idea affidare i file .sln al 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.

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

Solitamente inseriamo 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 addirittura considerare di non memorizzarlo nel controllo del codice sorgente sarebbe se avessi una soluzione di grandi dimensioni con molti progetti che era nel controllo del codice sorgente e volevi creare una soluzione di piccole dimensioni con alcuni dei progetti dal principale soluzione per alcuni requisiti transitori privati.

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

Conserviamo o risolviamo i file in Controllo versione TFS. 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 principale della soluzione viene utilizzato principalmente dal server di build.

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

1) Crea un nuovo progetto in VS
2) Fare clic con il tasto destro del mouse sulla soluzione in Esplora soluzioni, selezionare Aggiungi al controllo del codice sorgente

Lo sln è stato aggiunto al controllo del codice sorgente? Questa è la tua risposta.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow