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


841

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?


9
I file .suo vengono ricreati automaticamente. Un ottimo modo per "aggiornare" le impostazioni predefinite in caso di problemi.
Coding Barfield

3
Le migliori pratiche per i progetti Subversion e Visual Studio sono una domanda più generica su questo argomento esatto. Anche la risposta accettata contiene un collegamento alla documentazione ufficiale MSDN, che descrive in dettaglio quali file / directory di soluzioni / progetti VS devono essere aggiunti ai sistemi di controllo del codice sorgente e quali parti devono essere ignorate.
Attila Csipak,


Risposte:


673

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.


22
Fai attenzione, il suo file archivia le informazioni se il progetto è caricato / scaricato all'interno della soluzione.
Kugel,

5
Credo che memorizzi le informazioni di debug nel file .user (almeno per SQL Server Data Tools). Inoltre, quando si modificano le impostazioni nella scheda Debug, non è sempre persistito a .user immediatamente (la chiusura della soluzione sembra funzionare, un po 'fastidiosa ... o la modifica di un'altra impostazione memorizzata nel file .sqlproj).
Jamiebarrow,

87
Puoi aprire sia il file .user che .csproj in qualsiasi editor di testo. Ho appena provato a copiare e incollare le relative impostazioni di debug da .user in .csproj, quindi eliminare il file .user. Il debug ha continuato a funzionare, leggendo felicemente le impostazioni corrette dalla loro nuova posizione nel file .csproj. Ciò dovrebbe fornire un modo per eseguire il commit delle impostazioni di debug senza eseguire il commit del file .user. Assicurati di metterli nella giusta configurazione (debug, release, ecc.). Funziona sulla mia macchina! =)
Chris Nielsen,

139

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


19
Se lavori da solo su più macchine diverse varrebbe la pena aggiungerle?
thepocketwade,

33
Non lo farei, perché potrebbe essere fragile a differenze di sistema impreviste; per esempio, se lavori su x64 al lavoro e x86 a casa, allora potrebbe soffocare su "c: \ program files (x86)" e "c: \ program files". Non lo so, ma non rischierei.
Steve Cooper,

2
Sebbene contengano informazioni specifiche dell'utente, ma le informazioni dei file appena aggiunti tramite l'opzione (include in project) si trovano anche nel file .csproj, penso, il che richiede agli altri utenti di aggiungere manualmente tutte le risorse del progetto appena aggiunte. Se qualcuno conosce una soluzione alternativa, si prega di menzionare qui.
zeppelin,

69

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.

Dove e come viene svn:ignoreimpostata la proprietà?
Peter Mortensen,

@PeterMortensen, vedi questa domanda: stackoverflow.com/questions/86049/...
JXG

Ma c'è un caso (vedi questa risposta ) per aggiungere il .user, quindi si può scegliere di non ignorare solo .suo- oppure si può ignorare .user, in modo da prendere una decisione consapevole di aggiungerli? Non pensare, il punto svn:ignoreè segnare cose in cui non è necessaria alcuna decisione consapevole.
PJTraill,

49

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.


4
Sto anche iniziando a pensare che questo dovrebbe essere il caso: eseguire il commit del file utente in modo che gli sviluppatori in un team utilizzino le stesse impostazioni di debug. Se lo cambiano sulla propria macchina, va bene, purché il modo standard sia la versione nel controllo del codice sorgente.
Jamiebarrow,

1
Altri hanno suggerito di non farlo, ma non sono sicuro di quali possano essere i pericoli. Forse perché il file repo con impostazioni meno precise spazzerebbe via la copia locale (migliore) dell'utente? (Il nostro team sta usando Mercurial, BTW.)
Jon Coombs,

2
Microsoft sconsiglia di aggiungere il file .user al controllo del codice sorgente.
DavidRR

1
Puoi spostare le impostazioni di debug su .csproj, vedi questo commento
Timbo

26

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?


2
Il file SDF è probabilmente un database di SQL Server Compact Edition .
Carl G,

23

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).


20

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)


Inoltre, da MSDN: File Opzioni utente soluzione (.Suo) . La prima frase rende abbastanza chiaro l'intento di Microsoft: "Il file delle opzioni dell'utente della soluzione (.suo) contiene opzioni della soluzione per utente. Questo file non deve essere archiviato per il controllo del codice sorgente."
DavidRR

19

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.


12

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.


Avevo lasciato il file .sou e stava dando problemi a ricaricare i pacchetti. L'eliminazione del file .sou ha risolto il problema. Grazie.
mercedes,

11

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.


9

Non lo farei. Tutto ciò che potrebbe cambiare per "utente" di solito non è buono nel controllo del codice sorgente. .suo, .user, obj / bin directory


8

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.


7

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.


7

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.


5

.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.



4

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.


only the .sln & .*proj should be registered- non hai dimenticato molti file qui?
Lupo,

@Lupo oltre all'ovvio
Polluks

3

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.


2

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


1

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.


Anche i collegamenti simbolici funzionano molto bene a questo scopo.
sɐunıɔ ןɐ qɐp,

1

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.