Devo aggiungere i file .suo e .user di Visual Studio al controllo del codice sorgente?

Le soluzioni di Visual Studio contengono due tipi di file utente nascosti. Uno è il .suofile della soluzione che è un file binario. L'altro è il .userfile di progetto che è un file di testo. Esattamente quali dati contengono questi file?

Mi sono anche chiesto se avrei dovuto aggiungere questi file al controllo del codice sorgente (Subversion nel mio caso). Se non aggiungo questi file e un altro sviluppatore verifica la soluzione, Visual Studio creerà automaticamente i nuovi file utente?

Questi file contengono configurazioni delle preferenze dell'utente che sono generalmente specifiche per il tuo computer, quindi è meglio non inserirlo in SCM. Inoltre, VS lo cambierà quasi ogni volta che lo eseguirai, quindi sarà sempre contrassegnato da SCM come "modificato". Nemmeno io includo, sono in un progetto che usa VS per 2 anni e non ho avuto problemi a farlo. L'unico fastidio minore è che i parametri di debug (percorso di esecuzione, destinazione di distribuzione, ecc.) Sono memorizzati in uno di quei file (non so quale), quindi se hai uno standard per loro non sarai in grado di " pubblicarlo "tramite SCM affinché altri sviluppatori abbiano" pronto per l'uso "l'intero ambiente di sviluppo.

Non è necessario aggiungerli: contengono impostazioni per utente e altri sviluppatori non vorranno la tua copia.

Altri hanno spiegato perché avere *.suo e*.user file sotto il controllo del codice sorgente non sia una buona idea.

Vorrei suggerire di aggiungere questi schemi a svn:ignore proprietà per 2 motivi:

1. Quindi altri sviluppatori non finiranno con le impostazioni di uno sviluppatore.
2. Pertanto, quando visualizzi lo stato o esegui il commit dei file, tali file non ingombreranno la base di codice e oscureranno i nuovi file che devi aggiungere.

Non eseguiamo il commit del file binario (* .suo), ma impegniamo 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 sia di aiuto.

Da quando ho trovato questa domanda / risposta tramite 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 versione ( l'IDE li ricreerà). Dato che non ero sicuro che un file * .sdf potesse avere un uso legittimo altrove, ho ignorato solo il file specifico [projectname] .sdf da SVN.

Perché la procedura guidata di conversione di Visual Studio 2010 crea un enorme file di database SDF?

No, non dovresti aggiungerli al controllo del codice sorgente poiché, come hai detto, sono specifici dell'utente.

SUO (Opzioni utente soluzione): registra tutte le opzioni che è possibile associare alla soluzione in modo che ogni volta che la si apre includa le personalizzazioni effettuate.

Il file .user contiene le opzioni utente per il progetto (mentre SUO è per la soluzione) ed estende il nome del file di progetto (es. Anything.csproj.user contiene le impostazioni utente per il progetto anything.csproj).

Questo sembra essere l'opinione di Microsoft in materia:

Aggiunta (e modifica) di file .suo al controllo del codice sorgente

Non so perché il tuo progetto memorizzi la DebuggingWorkingDirectory nel suo file. Se si tratta di un'impostazione specifica dell'utente, dovresti considerare di salvarla nel nome file * .proj.user. Se tale impostazione è condivisibile tra tutti gli utenti che lavorano al progetto, dovresti considerare di memorizzarlo nel file di progetto stesso.

Non pensare nemmeno di aggiungere il suo file al controllo del codice sorgente! Il file SUO (soluton user options) è pensato per contenere impostazioni specifiche dell'utente e non deve essere condiviso tra gli utenti che lavorano sulla stessa soluzione. Se aggiungessi il file suo nel database scc, non so quali altre cose nell'IDE avresti rotto, ma dal punto di vista del controllo del codice interromperai l'integrazione scc dei progetti Web, il plug-in Lan vs Internet utilizzato da parte di utenti diversi per l'accesso VSS, e potresti persino causare la completa interruzione dell'scc (il percorso del database VSS memorizzato nel suo file potrebbe non essere valido per te potrebbe non essere valido per un altro utente).

Alin Constantin (MSFT)

Per impostazione predefinita, Microsoft Visual SourceSafe non include questi file nel controllo del codice sorgente poiché sono file di impostazioni specifici dell'utente. Seguirei 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 irregolare di VS nella casella degli sviluppatori. L'eliminazione del file e quindi la possibilità di ricreare VS risolveva sempre i problemi.

Sul sito Web MSDN , lo afferma chiaramente

Il file delle opzioni utente della soluzione (.suo) contiene opzioni della soluzione per utente. Questo file non deve essere archiviato per il controllo del codice sorgente .

Quindi direi che è abbastanza sicuro ignorare questi file mentre si fa il check-in del 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, obj / bin directory

Questi file sono opzioni specifiche dell'utente, che dovrebbero essere indipendenti dalla soluzione stessa. Visual Studio ne creerà di 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 crede.

Non è possibile controllare l'origine dei file .user, perché è specifico dell'utente. Contiene il nome della macchina remota e altre cose dipendenti dall'utente. È un file relativo a vcproj.

Il file .suo è un file relativo allo 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 contenga qualcosa di "relativo all'utente".

Nella nostra azienda non prendiamo questi file sotto il controllo del codice sorgente.

Contengono le impostazioni specifiche relative al 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 versione, lasciando che VS li ricrea in modo che ogni sviluppatore possa avere le impostazioni specifiche che desidera.

.user sono le impostazioni utente e penso che .suo sia la soluzione opzioni utente. Non vuoi questi file sotto il controllo del codice sorgente; saranno ricreati per ogni utente.

No.

Volevo solo una risposta breve e non ce n'era.

Utilizzando Rational ClearCase la risposta è no. Solo il .sln &. * Proj dovrebbe essere registrato nel controllo del codice sorgente.

Non posso rispondere per altri fornitori. Se ricordo bene, questi file sono opzioni specifiche "utente", il tuo ambiente.

Non aggiungere nessuno di questi file nel controllo versione. Questi file vengono generati automaticamente con informazioni specifiche sulla stazione di lavoro, se il check-in al controllo versione provoca problemi in altre stazioni di lavoro.

No, non dovrebbero impegnarsi nel controllo del codice sorgente in quanto sono impostazioni locali specifiche dello sviluppatore / della macchina.

GitHub mantiene un elenco di tipi di file suggeriti che gli utenti di Visual Studio possono ignorare https://github.com/github/gitignore/blob/master/VisualStudio.gitignore

Per svn, ho il seguente global-ignoreset di proprietà:

* .DotSettings.User
* .onetoc2
* .suo
.VS
PrecompiledWeb
thumbs.db
obj
bin
di debug
* .user
* .vshost. *
* .Tss
* .dbml.layout

Se si impostano le dipendenze della directory eseguibile in ProjectProperties> Debug> Ambiente , i percorsi vengono archiviati in file ".user".

Supponiamo di impostare questa stringa nel campo sopra menzionato: "PATH = C: \ xyz \ bin" Ecco come verrà memorizzata nel file '.user':

<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>

Questo ci ha aiutato molto lavorando in OpenCV. Potremmo usare diverse versioni di OpenCV per diversi progetti. Un altro vantaggio è che è stato molto semplice impostare i nostri progetti su una nuova macchina. Dovevamo solo copiare le dir di dipendenza 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.

Come spiegato in altre risposte, entrambi .suoe .usernon dovrebbero essere aggiunti al controllo del codice sorgente, poiché sono specifici dell'utente / della macchina (BTW .suoper le versioni più recenti di VS è stato spostato in una directory temporanea dedicata .vs, che dovrebbe essere completamente esclusa dal controllo del codice sorgente).

Tuttavia, se l'applicazione richiede una configurazione dell'ambiente per il debug in VS (tali impostazioni sono generalmente .userarchiviate), può essere utile preparare un file di esempio (denominandolo come .user.SAMPLE) e aggiungerlo al controllo del codice sorgente come riferimento.

Invece del percorso assoluto codificato in tale file, ha senso utilizzare quelli relativi o fare affidamento su variabili di ambiente, quindi l'esempio può essere abbastanza generico da essere facilmente riutilizzabile da altri.