Czy powinienem dodać pliki .suo i .user programu Visual Studio do kontroli źródła?

Rozwiązania Visual Studio zawierają dwa typy ukrytych plików użytkownika. Jednym z nich jest .suoplik rozwiązania , który jest plikiem binarnym. Drugi to .userplik projektu , który jest plikiem tekstowym. Dokładnie jakie dane zawierają te pliki?

Zastanawiam się także, czy powinienem dodać te pliki do kontroli źródła (w moim przypadku Subversion). Jeśli nie dodam tych plików, a inny programista sprawdzi rozwiązanie, czy program Visual Studio automatycznie utworzy nowe pliki użytkownika?

Te pliki zawierają konfiguracje preferencji użytkownika, które są ogólnie specyficzne dla twojego komputera, więc lepiej nie umieszczać go w SCM. Ponadto VS zmieni to prawie za każdym razem, gdy ją wykonasz, więc SCM zawsze będzie oznaczać ją jako „zmienioną”. Nie uwzględniam też, jestem w projekcie używającym VS przez 2 lata i nie miałem z tym problemu. Jedyną niewielką uciążliwością jest to, że parametry debugowania (ścieżka wykonania, cel wdrożenia itp.) Są przechowywane w jednym z tych plików (nie wiem, który), więc jeśli masz dla nich standard, nie będziesz w stanie „ opublikować „za pośrednictwem SCM, aby inni programiści mieli„ gotowe do użycia ”całe środowisko programistyczne.

Nie musisz ich dodawać - zawierają ustawienia dla poszczególnych użytkowników, a inni programiści nie będą chcieli Twojej kopii.

Inni wyjaśnili, dlaczego posiadanie plików *.suoi *.userpod kontrolą źródła nie jest dobrym pomysłem.

Chciałbym zasugerować dodanie tych wzorów do svn:ignorewłaściwości z 2 powodów:

1. Aby inni programiści nie skończyli z ustawieniami jednego programisty.
2. Kiedy więc przeglądasz status lub zatwierdzasz pliki, pliki te nie będą zaśmiecały bazy kodu i nie zasłaniały nowych plików, które musisz dodać.

Nie zatwierdzamy pliku binarnego (* .suo), ale zatwierdzamy plik .user. Plik .user zawiera na przykład opcje rozpoczęcia debugowania projektu. Opcje początkowe można znaleźć we właściwościach projektu w zakładce „Debugowanie”. W niektórych projektach używaliśmy NUnit i skonfigurowaliśmy nunit-gui.exe jako opcję uruchamiania projektu. Bez pliku .user każdy członek zespołu musiałby go skonfigurować osobno.

Mam nadzieję że to pomoże.

Ponieważ znalazłem to pytanie / odpowiedź w Google w 2011 roku, pomyślałem, że poświęcę chwilę i dodam link do plików * .SDF utworzonych przez Visual Studio 2010 do listy plików, które prawdopodobnie nie powinny zostać dodane do kontroli wersji ( IDE je odtworzy). Ponieważ nie byłem pewien, czy plik * .sdf może mieć uzasadnione zastosowanie w innym miejscu, zignorowałem tylko konkretny plik .sdf [nazwa projektu] z SVN.

Dlaczego kreator konwersji Visual Studio 2010 tworzy ogromny plik bazy danych SDF?

Nie, nie powinieneś dodawać ich do kontroli źródła, ponieważ - jak powiedziałeś - są one specyficzne dla użytkownika.

SUO (Opcje użytkownika rozwiązania): Rejestruje wszystkie opcje, które możesz powiązać z rozwiązaniem, aby za każdym razem, gdy je otwierasz, zawierało dokonane przez Ciebie dostosowania.

Plik .user zawiera opcje użytkownika dla projektu (podczas gdy SUO jest rozwiązaniem) i rozszerza nazwę pliku projektu (np. Cokolwiek.csproj.user zawiera ustawienia użytkownika dla projektu cokolwiek. Csproj).

Wydaje się, że jest to opinia Microsoftu w tej sprawie:

Dodawanie (i edycja) plików .suo do kontroli źródła

Nie wiem, dlaczego twój projekt przechowuje DebuggingWorkingDirectory w pliku suo. Jeśli jest to ustawienie specyficzne dla użytkownika, należy rozważyć zapisanie go w nazwie pliku * .proj.user. Jeśli ustawienie to można udostępnić wszystkim użytkownikom pracującym nad projektem, należy rozważyć zapisanie go w samym pliku projektu.

Nawet nie myśl o dodaniu pliku suo do kontroli źródła! Plik SUO (soluton user options) ma zawierać ustawienia specyficzne dla użytkownika i nie powinien być udostępniany użytkownikom pracującym nad tym samym rozwiązaniem. Jeśli chcesz dodać plik suo do bazy danych scc, nie wiem, jakie inne rzeczy w IDE złamałeś, ale z punktu widzenia kontroli źródła zepsujesz integrację projektów internetowych scc, użyto wtyczki Lan vs Internet przez różnych użytkowników dla dostępu VSS, a może nawet spowodować całkowite uszkodzenie scc (ścieżka bazy danych VSS przechowywana w pliku suo, która może być dla Ciebie ważna, może nie być ważna dla innego użytkownika).

Alin Constantin (MSFT)

Domyślnie Visual SourceSafe firmy Microsoft nie włącza tych plików do kontroli źródła, ponieważ są to pliki ustawień specyficzne dla użytkownika. Podążałbym za tym modelem, jeśli używasz SVN jako kontroli źródła.

Visual Studio je automatycznie utworzy. Nie polecam poddania ich kontroli źródła. Wiele razy plik SOU lokalnego programisty powodował, że VS zachowywał się nieprawidłowo na tym polu programisty. Usunięcie pliku, a następnie umożliwienie jego odtworzenia przez VS zawsze rozwiązało problemy.

Na stronie MSDN wyraźnie to stwierdza

Plik opcji użytkownika rozwiązania (.suo) zawiera opcje rozwiązania dla poszczególnych użytkowników. Ten plik nie powinien być rejestrowany w celu kontroli kodu źródłowego .

Powiedziałbym więc, że całkiem bezpiecznie jest zignorować te pliki podczas sprawdzania elementów w kontroli źródła.

Nie zrobiłbym tego. Wszystko, co mogłoby się zmienić na „użytkownika”, zwykle nie jest dobre w kontroli źródła. .suo, .user, obj / bin katalogi

Te pliki są opcjami specyficznymi dla użytkownika, które powinny być niezależne od samego rozwiązania. Visual Studio utworzy nowe w razie potrzeby, więc nie trzeba ich rejestrować w celu kontroli źródła. Rzeczywiście, prawdopodobnie lepiej byłoby tego nie robić, ponieważ pozwala to indywidualnym programistom dostosowywać swoje środowisko według własnego uznania.

Nie można sterować źródłami plików .user, ponieważ są one specyficzne dla użytkownika. Zawiera nazwę zdalnego komputera i inne rzeczy zależne od użytkownika. Jest to plik związany z vcproj.

Plik .suo jest plikiem powiązanym z SLN i zawiera „opcje użytkownika rozwiązania” (projekty startowe), położenie systemu Windows (co jest zadokowane i gdzie, co jest zmiennoprzecinkowe) itp.)

Jest to plik binarny i nie wiem, czy zawiera coś „związanego z użytkownikiem”.

W naszej firmie nie bierzemy tych plików pod kontrolę źródła.

Zawierają one specyficzne ustawienia dotyczące projektu, które zwykle są przypisane do jednego programisty (na przykład projekt początkowy i strona początkowa, które mają się rozpocząć podczas debugowania aplikacji).

Lepiej więc nie dodawać ich do kontroli wersji, pozostawiając VS odtworzyć je, aby każdy programista mógł mieć określone ustawienia.

.user to ustawienia użytkownika i myślę, że .suo to opcje użytkownika rozwiązania. Nie chcesz, aby te pliki były pod kontrolą źródła; zostaną one ponownie utworzone dla każdego użytkownika.

Nie.

Chciałem tylko naprawdę krótkiej odpowiedzi, a żadnej nie było.

Przy użyciu produktu Rational ClearCase odpowiedź brzmi „nie”. W kontroli kodu źródłowego należy zarejestrować tylko .sln &. * Proj.

Nie mogę odpowiadać za innych dostawców. Jeśli dobrze pamiętam, te pliki są opcjami specyficznymi dla użytkownika, twojego środowiska.

Nie dodawaj żadnego z tych plików do kontroli wersji. Pliki te są generowane automatycznie na podstawie informacji specyficznych dla stacji roboczej, jeśli zostaną zarejestrowane w kontroli wersji, co spowoduje problemy na innych stacjach roboczych.

Nie, nie powinni być zobowiązani do kontroli źródła, ponieważ są to ustawienia lokalne specyficzne dla programistów / komputerów.

GitHub prowadzi listę sugerowanych typów plików do zignorowania przez użytkowników Visual Studio na https://github.com/github/gitignore/blob/master/VisualStudio.gitignore

Dla svn mam następujący global-ignorezestaw właściwości:

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

Jeśli ustawisz zależności pliku wykonywalnego w ProjectProperties> Debugowanie> Środowisko , ścieżki są przechowywane w plikach „.user”.

Załóżmy, że ustawiłem ten ciąg w wyżej wspomnianym polu: „ŚCIEŻKA = C: \ xyz \ bin” W ten sposób zostanie zapisany w pliku „.user”:

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

To bardzo nam pomogło podczas pracy w OpenCV. Możemy użyć różnych wersji OpenCV do różnych projektów. Kolejną zaletą jest to, że bardzo łatwo było skonfigurować nasze projekty na nowej maszynie. Musieliśmy po prostu skopiować odpowiednie katalogi zależności. Dlatego w przypadku niektórych projektów wolę dodać „.user” do kontroli źródła.

Mimo to jest całkowicie zależny od projektów. Możesz odebrać połączenie w zależności od potrzeb.

Jak wyjaśniono w innych odpowiedzi, zarówno .suoi .usernie powinien być dodany do kontroli źródła, ponieważ są one user / maszyna specyficzne (BTW .suona najnowszych wersjach VS została przeniesiona do specjalnego katalogu tymczasowego .vs, które powinny być przechowywane w miejscu kontroli źródła całkowicie).

Jeśli jednak aplikacja wymaga pewnej konfiguracji środowiska do debugowania w VS (takie ustawienia są zwykle przechowywane w .userpliku), może być przydatne przygotowanie przykładowego pliku (nadanie mu nazwy .user.SAMPLE) i dodanie go do kontroli źródła w celu uzyskania referencji.

Zamiast zakodowanej na stałe ścieżki bezwzględnej w takim pliku, sensowne jest użycie względnych lub poleganie na zmiennych środowiskowych, więc próbka może być wystarczająco ogólna, aby inni mogli z niej łatwo korzystać.