Devo aggiungere i file Visual Studio .suo e .user al controllo del codice sorgente?
Le soluzioni di Visual Studio contengono due tipi di file utente nascosti. Uno è la soluzione .suo che è un file binario. L'altro è il file .user del progetto che è un file di testo. Esattamente quali dati contengono questi file?
Mi sono anche chiesto se dovrei aggiungere questi file al controllo del codice sorgente (Subversion nel mio caso). Se non aggiungo questi file e un altro sviluppatore controlla la soluzione, Visual Studio creerà automaticamente nuovi file utente?
Questi file contengono configurazioni delle preferenze utente che sono in generale specifiche per la macchina, quindi è meglio non inserirle in SCM. Inoltre, VS lo cambierà quasi ogni volta che lo esegui, quindi sarà sempre contrassegnato da SCM come 'cambiato' . Non includo neanche, sono in un progetto usando VS da 2 anni e ho nessun problema a farlo. L'unica piccola seccatura è che i parametri di debug (percorso di esecuzione, destinazione di implementazione, ecc.) Sono memorizzati in uno di questi file (non so quale), quindi se hai uno standard per loro non sarai in grado di ' pubblicare "via SCM per altri sviluppatori affinché l'intero ambiente di sviluppo sia pronto per l'uso".
Non è necessario aggiungerli: contengono impostazioni per utente e altri sviluppatori non vorranno la tua copia.
Altri hanno spiegato perché avere i file *.suo e *.user sotto il controllo del codice sorgente non è una buona idea.
Vorrei suggerire di aggiungere questi pattern alla proprietà svn:ignore per 2 motivi:
- Quindi, gli altri sviluppatori non si fermeranno Con le impostazioni di uno sviluppatore.
- Pertanto, quando si visualizzano i file di stato o commit , Questi file non ingombrano il codice base e oscurano i nuovi file che è necessario aggiungere.
Non impegniamo il file binario (* .suo), ma commettiamo il file .user. Il file .user contiene ad esempio le opzioni di avvio per il debug del progetto. Puoi trovare le opzioni di avvio nelle proprietà del progetto nella scheda "Debug". Abbiamo usato NUnit in alcuni progetti e configurato nunit-gui.exe come opzione di avvio per il progetto. Senza il file .user, ogni membro del team dovrebbe configurarlo separatamente.
Spero che questo ti aiuti.
Poiché ho trovato questa domanda/risposta attraverso Google nel 2011, ho pensato di prendere un secondo e aggiungere il collegamento per i file * .SDF creati da Visual Studio 2010 all'elenco di file che probabilmente non dovrebbero essere aggiunti al controllo di versione ( IDE li ricrearà). Poiché non ero sicuro che un file * .sdf potesse avere un uso legittimo altrove, ho ignorato solo il file specifico [projectname] .sdf di SVN.
No, non dovresti aggiungerli al controllo del codice sorgente poiché - come hai detto tu - sono specifici per l'utente.
SUO (Opzioni utente soluzione): Records tutte le opzioni che potresti associarsi con la soluzione in modo che ogni volta che lo apri, include personalizzazioni che tu hanno fatto.
Il file .user contiene le opzioni utente per il progetto (mentre SUO è per la soluzione) e estende il nome del file di progetto (ad esempio anything.csproj.user contiene le impostazioni utente per il progetto anything.csproj).
Questo sembra essere l'opinione di Microsoft sull'argomento:
Aggiunta (e modifica) di file .suo al controllo del codice sorgente
Non so perché il tuo progetto memorizza DebuggingWorkingDirectory in il suo file. Se questa è un'impostazione specifica per l'utente dovresti considerare memorizzandolo nel nome file * .proj.user. Se questa impostazione è condivisibile tra tutti gli utenti che lavorano al progetto dovresti considerare la memorizzazione di nel file di progetto stesso.
Non pensare nemmeno di aggiungere il suo file al controllo del codice sorgente! Il SUO Il file (opzioni utente di soluton) è pensato per contenere specifiche impostazioni, e non dovrebbero essere condivise tra gli utenti che lavorano sullo stesso soluzione. Se dovessi aggiungere il suo file nel database scc, non lo farei sapere quali altre cose nel IDE dovresti interrompere, ma dal controllo del codice sorgente punto di vista si interromperà l'integrazione scc di progetti web, la Lan vs Plugin Internet utilizzato da diversi utenti per l'accesso VSS e potresti persino causare la rottura dell'intercettazione scc (il percorso del database VSS memorizzato nel file suo che potrebbe essere valido per voi potrebbe non essere valido per un altro utente).
Alin Constantin (MSFT)
Per impostazione predefinita, Visual SourceSafe di Microsoft non include questi file nel controllo origine perché sono file di impostazioni specifici dell'utente. Seguirò quel modello se stai usando SVN come controllo del codice sorgente.
Visual Studio li creerà automaticamente. Non consiglio di metterli nel controllo del codice sorgente. Ci sono state numerose volte in cui il file SOU di uno sviluppatore locale stava causando un comportamento errato di VS su quella casella degli sviluppatori. Eliminando il file e quindi consentendo a VS di ricrearlo, è sempre stato risolto il problema.
Sul sito Web MSDN , lo afferma chiaramente
Il file delle opzioni utente della soluzione (.suo) contiene la soluzione per utente opzioni. Questo file non deve essere archiviato nel controllo del codice sorgente.
Quindi direi che è abbastanza sicuro ignorare questi file durante il check-in per il controllo del codice sorgente.
Non lo farei. Tutto ciò che potrebbe cambiare per "utente" di solito non è buono nel controllo del codice sorgente. .suo, .user, directory obj/bin
Questi file sono opzioni specifiche dell'utente, che dovrebbero essere indipendenti dalla soluzione stessa. Visual Studio creerà dei nuovi se necessario, quindi non è necessario effettuare il check-in per il controllo del codice sorgente. In effetti, probabilmente sarebbe meglio non farlo in quanto ciò consente ai singoli sviluppatori di personalizzare il proprio ambiente come meglio credono.
Non puoi controllare il codice sorgente dei file .user, perché è specifico per l'utente. Contiene il nome della macchina remota e altre cose dipendenti dall'utente. È un file correlato a vcproj.
Il file .suo è un file relativo a sln e contiene le "opzioni utente della soluzione" (progetti di avvio, posizione di Windows (cosa è ancorato e dove, cosa è mobile), ecc.)
È un file binario e non so se contiene qualcosa di "connesso all'utente".
Nella nostra azienda non portiamo questi file sotto il controllo del codice sorgente.
Contengono le impostazioni specifiche sul progetto che sono in genere assegnate a un singolo sviluppatore (come, ad esempio, il progetto iniziale e la pagina iniziale da avviare quando si esegue il debug dell'applicazione).
Quindi è meglio non aggiungerli al controllo di versione, lasciando VS a ricrearli in modo che ogni sviluppatore possa avere le impostazioni specifiche che desidera.
.user è le impostazioni utente e penso che .suo sia la soluzione per gli utenti della soluzione. Non vuoi questi file sotto il controllo del codice sorgente; saranno ricreati per ogni utente.
Usando Rational ClearCase la risposta è no. Solo il file .sln &. * Proj deve essere registrato nel controllo del codice sorgente.
Non posso rispondere per altri venditori. Se ricordo correttamente, questi file sono opzioni specifiche "utente", il tuo ambiente.
Non aggiungere nessuno di questi file nel controllo di versione. Questi file vengono generati automaticamente con informazioni specifiche della stazione di lavoro, se il check-in per il controllo della versione che causerà problemi in altre stazioni di lavoro.
No, non dovrebbero essere impegnati nel controllo del codice sorgente in quanto sono impostazioni locali specifiche per lo sviluppatore/macchina.
GitHub mantiene un elenco di tipi di file suggeriti per gli utenti di Visual Studio da ignorare in https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
Per svn, ho il seguente insieme di proprietà global-ignore:
* .DotSettings.User
* .onetoc2
* .suo
.VS
PrecompiledWeb
thumbs.db
obj
bidone
mettere a punto
*.utente
* .Vshost. *
* .tss
* .dbml.layout
Come spiegato in altre risposte, sia .suo che .user non dovrebbero essere aggiunti al controllo del codice sorgente, poiché sono specifici dell'utente/macchina (BTW .suo per le versioni più recenti di VS è stato spostato nella directory temporanea dedicata .vs, che dovrebbe essere tenuto fuori dalla fonte controllo completamente).
Tuttavia se la tua applicazione richiede qualche setup di ambiente per il debugging in VS (tali impostazioni sono solitamente contenute nel file .user), può essere utile preparare un file di esempio (nominandolo come .user.SAMPLE) e aggiungerlo al controllo del codice sorgente per Riferimenti.
Invece del percorso assoluto codificato in tale file, ha senso utilizzare quelli relativi o fare affidamento su variabili di ambiente, quindi il campione può essere abbastanza generico da essere facilmente riutilizzabile da altri.
Se si impostano le dipendenze dir eseguibili in ProprietàProgetti> Debug> Ambiente , i percorsi vengono memorizzati nei file "utente".
Supponiamo di aver impostato questa stringa nel campo sopra indicato: "PATH = C:\xyz\bin" Ecco come verrà memorizzato nel file '.user':
<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>
Questo ci ha aiutato molto mentre lavoravamo in OpenCV. Potremmo usare diverse versioni di OpenCV per diversi progetti. Un altro vantaggio è che è stato molto facile impostare i nostri progetti su una nuova macchina. Dovevamo solo copiare le directory delle dipendenze corrispondenti. Quindi per alcuni progetti, preferisco aggiungere ".user" al controllo del codice sorgente.
Anche se, dipende interamente dai progetti. Puoi rispondere a una chiamata in base alle tue esigenze.