Soluțiile Visual Studio conțin două tipuri de fișiere utilizator ascunse. Unul este fișierul soluție .suo care este un fișier binar. Celălalt este fișierul proiect .user care este un fișier text. Exact ce date conțin aceste fișiere?
De asemenea, m-am întrebat dacă ar trebui să adaug aceste fișiere la controlul sursei (Subversion în cazul meu). Dacă nu adaug aceste fișiere și un alt dezvoltator verifică soluția, Visual Studio va crea automat noi fișiere utilizator?
Aceste fișiere conțin configurații ale preferințelor utilizatorului care sunt în general specifice mașinii dvs., așa că este mai bine să nu le puneți în SCM. De asemenea, VS îl va schimba aproape de fiecare dată când îl executați, așa că va fi întotdeauna marcat de SCM ca „schimbat”. Nici eu nu includ, sunt într-un proiect folosind VS de 2 ani și nu am avut probleme în a face asta. Singura supărare minoră este că parametrii de depanare (cale de execuție, țintă de implementare etc.) sunt stocați într-unul dintre acele fișiere (nu știu care), așa că, dacă aveți un standard pentru ei, nu veți putea " publicați-l prin SCM pentru ca alți dezvoltatori să aibă întregul mediu de dezvoltare „gata de utilizat”.
Nu trebuie să le adăugați -- conțin setări pentru fiecare utilizator, iar alți dezvoltatori nu vor dori copia dvs.
Alții au explicat de ce a avea fișierele *.suo și *.user sub control sursă nu este o idee bună.
Aș dori să vă sugerez să adăugați aceste modele la proprietatea svn:ignore din două motive:
svn:ignore?
- person Peter Mortensen; 21.04.2015
.user, așa că atunci se poate alege să nu ignore doar .suo – sau s-ar putea ignora .user, astfel încât să fie nevoie de o decizie conștientă pentru a le adăuga? Nu credeți, scopul lui svn:ignore este să marcheze lucrurile în care nu este nevoie de o decizie conștientă.
- person PJTraill; 27.05.2015
Nu comitem fișierul binar (*.suo), dar comitem fișierul .user. Fișierul .user conține, de exemplu, opțiunile de pornire pentru depanarea proiectului. Puteți găsi opțiunile de pornire în proprietățile proiectului în fila „Depanare”. Am folosit NUnit în unele proiecte și am configurat nunit-gui.exe ca opțiune de pornire pentru proiect. Fără fișierul .user, fiecare membru al echipei ar trebui să-l configureze separat.
Sper că acest lucru vă ajută.
Deoarece am găsit această întrebare/răspuns prin Google în 2011, m-am gândit să iau o secundă și să adaug linkul pentru fișierele *.SDF create de Visual Studio 2010 la lista de fișiere care probabil nu ar trebui adăugate la controlul versiunilor ( IDE-ul le va re-crea). Deoarece nu eram sigur că un fișier *.sdf poate avea o utilizare legitimă în altă parte, am ignorat doar fișierul specific [projectname].sdf din SVN.
De ce asistentul de conversie Visual Studio 2010 creează un fișier masiv de bază de date SDF?
Nu, nu ar trebui să le adăugați la controlul sursă deoarece - după cum ați spus - sunt specifice utilizatorului.
SUO (Solution User Options): Înregistrează toate opțiunile pe care le-ați putea asocia cu soluția dvs., astfel încât de fiecare dată când o deschideți, aceasta include personalizările pe care le-ați făcut.
Fișierul .user conține opțiunile utilizatorului pentru proiect (în timp ce SUO este pentru soluție) și extinde numele fișierului de proiect (de exemplu, anything.csproj.user conține setările utilizatorului pentru proiectul anything.csproj).
Aceasta pare a fi opinia Microsoft cu privire la această problemă:
Adăugarea (și editarea ) Fișierele .suo la controlul sursei
Nu știu de ce proiectul dvs. stochează DebuggingWorkingDirectory în fișierul suo. Dacă aceasta este o setare specifică utilizatorului, ar trebui să luați în considerare stocarea acesteia în numele fișierului *.proj.user. Dacă această setare poate fi partajată între toți utilizatorii care lucrează la proiect, ar trebui să luați în considerare stocarea acesteia în fișierul de proiect în sine.
Nu vă gândiți să adăugați fișierul suo la controlul sursei! Fișierul SUO (opțiuni utilizator soluție) este menit să conțină setări specifice utilizatorului și nu ar trebui să fie partajat între utilizatorii care lucrează la aceeași soluție . Dacă ați adăuga fișierul suo în baza de date scc, nu știu ce alte lucruri în IDE ați sparge, dar din punct de vedere al controlului sursei veți întrerupe integrarea proiectelor web scc, pluginul Lan vs Internet folosit de către diferiți utilizatori pentru accesul VSS, și ați putea chiar provoca ruperea completă a scc (calea bazei de date VSS stocată în fișierul suo care poate fi valabilă pentru dvs. poate să nu fie valabilă pentru alt utilizator).
Alin Constantin (MSFT)
În mod implicit, Visual SourceSafe de la Microsoft nu include aceste fișiere în controlul sursă deoarece sunt fișiere de setări specifice utilizatorului. Aș urma acel model dacă utilizați SVN ca control sursă.
Visual Studio le va crea automat. Nu recomand să le puneți în controlul sursei. Au existat de multe ori în care fișierul SOU al unui dezvoltator local a determinat VS să se comporte neregulat în acea casetă de dezvoltatori. Ștergerea fișierului și apoi lăsarea lui VS să-l recreeze a rezolvat întotdeauna problemele.
Pe site-ul web MSDN, se afirmă clar că
Fișierul opțiuni pentru utilizatorul soluției (.suo) conține opțiuni de soluție pentru fiecare utilizator. Acest fișier nu ar trebui să fie înregistrat în controlul codului sursă.
Așa că aș spune că este destul de sigur să ignori aceste fișiere în timp ce înregistrezi lucruri în controlul sursei.
nu aș face-o. Orice lucru care s-ar putea schimba pe „utilizator” nu este de obicei bun în controlul sursei. directoare .suo, .user, obj/bin
No.
Am vrut doar un răspuns foarte scurt și nu a existat.
Aceste fișiere sunt opțiuni specifice utilizatorului, care ar trebui să fie independente de soluția în sine. Visual Studio va crea altele noi după cum este necesar, astfel încât acestea nu trebuie să fie verificate în controlul sursei. Într-adevăr, probabil ar fi mai bine să nu o faci, deoarece acest lucru le permite dezvoltatorilor individuali să-și personalizeze mediul după cum consideră de cuviință.
Nu puteți controla prin sursă fișierele .user, deoarece acestea sunt specifice utilizatorului. Conține numele mașinii de la distanță și alte lucruri dependente de utilizator. Este un fișier legat de vcproj.
Fișierul .suo este un fișier legat de sln și conține „opțiunile utilizatorului soluției” (proiect(e) de pornire, poziția ferestrelor (ce este andocat și unde, ce plutește), etc.)
Este un fișier binar și nu știu dacă conține ceva „relativ cu utilizatorul”.
În compania noastră nu luăm acele fișiere sub controlul sursei.
Acestea conțin setările specifice despre proiect care sunt de obicei atribuite unui singur dezvoltator (cum ar fi, de exemplu, proiectul de pornire și pagina de pornire care urmează să înceapă atunci când depanați aplicația).
Deci, este mai bine să nu le adăugați la controlul versiunilor, lăsând VS să le recreeze, astfel încât fiecare dezvoltator să aibă setările specifice pe care le dorește.
.user sunt setările utilizatorului și cred că .suo sunt opțiunile utilizatorului soluției. Nu doriți ca aceste fișiere să fie sub controlul sursei; acestea vor fi re-create pentru fiecare utilizator.
Utilizând Rational ClearCase, răspunsul este nu. Doar .sln & .*proj ar trebui să fie înregistrate în controlul codului sursă.
Nu pot răspunde pentru alți furnizori. Dacă îmi amintesc corect, aceste fișiere sunt opțiuni specifice „utilizatorului”, mediul dumneavoastră.
only the .sln & .*proj should be registered - nu ai uitat o mulțime de fișiere aici?
- person Wolf; 14.12.2016
Nu adăugați niciunul dintre aceste fișiere în controlul versiunilor. Aceste fișiere sunt generate automat cu informații specifice stației de lucru, dacă sunt înregistrate în controlul versiunilor, ceea ce va cauza probleme în alte stații de lucru.
Nu, nu ar trebui să fie implicați în controlul sursei, deoarece sunt setări locale specifice dezvoltatorului/mașinii.
GitHub menține o listă de tipuri de fișiere sugerate pentru ca utilizatorii Visual Studio să le ignore la https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
Pentru svn, am următorul set de proprietăți global-ignore:
*.DotSettings.User
*.onetoc2
*.suo
.vs
PrecompiledWeb
thumbs.db
obj
bin
depanare
*.user
*.vshost.*
*.tss
*.dbml.layout
Alții au explicat că nu, nu vrei asta în controlul versiunilor. Ar trebui să configurați sistemul de control al versiunilor pentru a ignora fișierul (de exemplu, printr-un fișier .gitignore).
Pentru a înțelege cu adevărat de ce, vă ajută să vedeți ce este de fapt în acest fișier. Am scris un instrument de linie de comandă care vă permite să vedeți conținutul fișierului .suo.
Instalați-l pe mașina dvs. prin:
dotnet tool install -g suo
Are două sub-comenzi, keys și view.
suo keys <path-to-suo-file>
Acest lucru va elimina cheia pentru fiecare valoare din fișier. De exemplu (prescurtat):
nuget
ProjInfoEx
BookmarkState
DebuggerWatches
HiddenSlnFolders
ObjMgrContentsV8
UnloadedProjects
ClassViewContents
OutliningStateDir
ProjExplorerState
TaskListShortcuts
XmlPackageOptions
BackgroundLoadData
DebuggerExceptions
DebuggerFindSource
DebuggerFindSymbol
ILSpy-234190A6EE66
MRU Solution Files
UnloadedProjectsEx
ApplicationInsights
DebuggerBreakpoints
OutliningStateV1674
...
După cum puteți vedea, multe caracteristici IDE folosesc acest fișier pentru a-și stoca starea.
Utilizați comanda view pentru a vedea valoarea unei chei date. De exemplu:
$ suo view nuget --format=utf8 .suo
nuget
?{"WindowSettings":{"project:MyProject":{"SourceRepository":"nuget.org","ShowPreviewWindow":false,"ShowDeprecatedFrameworkWindow":true,"RemoveDependencies":false,"ForceRemove":false,"IncludePrerelease":false,"SelectedFilter":"UpdatesAvailable","DependencyBehavior":"Lowest","FileConflictAction":"PromptUser","OptionsExpanded":false,"SortPropertyName":"ProjectName","SortDirection":"Ascending"}}}
Mai multe informații despre instrument aici: https://github.com/drewnoakes/suo
Dacă setați dependențele directorului executabil în ProjectProperties>Debugging>Environment, căile sunt stocate în fișiere „.user”.
Să presupunem că am setat acest șir în câmpul menționat mai sus: "PATH=C:\xyz\bin" Acesta este modul în care va fi stocat în fișierul „.user”:
<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>
Acest lucru ne-a ajutat foarte mult în timp ce lucram în OpenCV. Am putea folosi diferite versiuni de OpenCV pentru diferite proiecte. Un alt avantaj este că a fost foarte ușor să ne instalăm proiectele pe o mașină nouă. A trebuit doar să copiem direcțiile de dependență corespunzătoare. Deci, pentru unele proiecte, prefer să adaug „.user” la controlul sursei.
Chiar dacă, depinde în întregime de proiecte. Puteți prelua un apel în funcție de nevoile dvs.
După cum se explică în alte răspunsuri, atât .suo, cât și .user nu ar trebui adăugate la controlul sursei, deoarece sunt specifice utilizatorului/mașinii (BTW .suo pentru cele mai noi versiuni de VS a fost mutat în directorul temporar dedicat .vs, care ar trebui să fie păstrat în afara sursei). controlează complet).
Cu toate acestea, dacă aplicația dvs. necesită o anumită configurare a mediului pentru depanare în VS (astfel de setări sunt de obicei păstrate în fișierul .user), poate fi util să pregătiți un fișier exemplu (numindu-l ca .user.SAMPLE) și să îl adăugați la controlul sursei pentru referințe.
În loc de calea absolută codificată în acest fișier, este logic să folosiți cele relative sau să vă bazați pe variabilele de mediu, astfel încât eșantionul poate fi suficient de generic pentru a fi ușor reutilizabil de către alții.
