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 file 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 che usa VS da 2 anni e non ho avuto problemi 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 *.suo e *.user sotto il controllo del codice sorgente non è una buona idea.

Vorrei suggerire di aggiungere questi modelli alla proprietà svn:ignore per 2 motivi:

  1. Quindi gli altri sviluppatori non finiranno con le impostazioni di uno sviluppatore.
  2. Pertanto, quando si visualizzano lo stato o si impegnano i file, 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.

Da quando ho trovato questa domanda / risposta attraverso Google nel 2011, ho pensato di prendere un secondo e aggiungere il link per i file * .SDF creati da Visual Studio 2010 all’elenco di file che probabilmente non dovrebbero essere aggiunti al controllo di versione ( l’IDE li ricreterà). Poiché non ero sicuro che un file * .sdf potesse avere un uso legittimo altrove, ho ignorato solo il file specifico [projectname] .sdf di 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 tu – sono specifici per l’utente.

SUO (Opzioni utente soluzione): registra tutte le opzioni che è ansible associare alla soluzione in modo che ogni volta che viene aperta, include le personalizzazioni effettuate.

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, any.csproj.user contiene le impostazioni utente per il progetto anything.csproj).

Per impostazione predefinita, Microsoft Visual SourceSafe non include questi file nel controllo del codice sorgente perché sono file di impostazioni specifici dell’utente. Seguirò quel modello se stai usando SVN come controllo del codice sorgente.

Questo sembra essere l’opinione di Microsoft sull’argomento: http://social.msdn.microsoft.com/forums/en-US/vssourcecontrol/thread/dee90d75-d825-4c76-a30f-016eab15ef7f

Non so perché il tuo progetto memorizza DebuggingWorkingDirectory nel suo file. Se si tratta di un’impostazione specifica per l’utente, è consigliabile archiviarla nel nome file * .proj.user. Se questa impostazione è condivisibile tra tutti gli utenti che lavorano al progetto, dovresti considerare di archiviarla nel file di progetto stesso.

Non pensate nemmeno di aggiungere il suo file al controllo del codice sorgente! Il file SUO (soluton user options) ha lo scopo di contenere le impostazioni specifiche dell’utente e non deve essere condiviso tra gli utenti che lavorano sulla stessa soluzione. Se dovessi aggiungere il suo file nel database scc, non so quali altre cose nell’IDE si spezzino, ma dal punto di vista del controllo del codice sorgente interromperesti l’integrazione di progetti Web scc, il plugin Lan vs Internet usato da utenti diversi per l’accesso VSS, e si potrebbe persino causare un’interruzione completa dello scc (il percorso del database VSS memorizzato nel suo file che potrebbe essere valido per voi potrebbe non essere valido per un altro utente).

Alin Constantin (MSFT)

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 di opzioni utente (.suo) contiene opzioni di soluzione per utente. 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 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 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 sln correlato 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 dell’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 .sln &. * Proj dovrebbe essere registrato nel controllo del codice sorgente, non posso rispondere per altri fornitori. Se ricordo correttamente questi file sono opzioni specifiche “utente”, il tuo ambiente.

Se si impostano le dipendenze dir eseguibili in ProjectProperties> 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’:

PATH=C:\xyz\bin$(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 semplice 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.