Sollte ich die Visual Studio-Dateien .suo und .user zur Quellcodeverwaltung hinzufügen?

Visual Studio-Lösungen enthalten zwei Arten von versteckten Benutzerdateien. Eine ist die Lösungsdatei .suo, die eine Binärdatei ist. Die andere ist die Projektdatei .user, die eine Textdatei ist. Welche Daten enthalten diese Dateien genau?

Ich habe mich auch gefragt, ob ich diese Dateien zur Quellcodeverwaltung hinzufügen soll (in meinem Fall Subversion). Wenn ich diese Dateien nicht hinzufüge und ein anderer Entwickler die Lösung auscheckt, erstellt Visual Studio dann automatisch neue Benutzerdateien?

Diese Dateien enthalten Benutzereinstellungen, die im Allgemeinen für Ihren Computer spezifisch sind. Es ist daher besser, sie nicht in SCM zu speichern. Außerdem ändert VS es fast jedes Mal, wenn Sie es ausführen, sodass es vom SCM immer als "geändert" markiert wird. Ich schließe auch nicht ein, ich bin seit 2 Jahren in einem Projekt mit VS und hatte keine Probleme damit. Das einzige kleine Ärgernis ist, dass die Debug-Parameter (Ausführungspfad, Bereitstellungsziel usw.) in einer dieser Dateien gespeichert sind (ich weiß nicht, welche). Wenn Sie also einen Standard für sie haben, können Sie dies nicht. ' Veröffentlichen Sie es über SCM, damit andere Entwickler die gesamte Entwicklungsumgebung einsatzbereit haben.

Sie müssen diese nicht hinzufügen - sie enthalten Einstellungen pro Benutzer, und andere Entwickler möchten Ihre Kopie nicht.

Andere haben erklärt, warum es keine gute Idee ist , die *.suound *.user-Dateien unter Quellcodeverwaltung zu haben.

Ich möchte vorschlagen, dass Sie diese Muster svn:ignoreaus zwei Gründen zur Eigenschaft hinzufügen :

1. Andere Entwickler werden also nicht mit den Einstellungen eines Entwicklers enden.
2. Wenn Sie also den Status anzeigen oder Dateien festschreiben, werden diese Dateien die Codebasis nicht überladen und neue Dateien, die Sie hinzufügen müssen, verdecken.

Wir schreiben die Binärdatei (* .suo) nicht fest, sondern die .user-Datei. Die .user-Datei enthält beispielsweise die Startoptionen zum Debuggen des Projekts. Die Startoptionen finden Sie in den Eigenschaften des Projekts auf der Registerkarte "Debuggen". Wir haben NUnit in einigen Projekten verwendet und die nunit-gui.exe als Startoption für das Projekt konfiguriert. Ohne die .user-Datei müsste jedes Teammitglied sie separat konfigurieren.

Hoffe das hilft.

Da ich diese Frage / Antwort 2011 über Google gefunden habe, dachte ich, ich würde mir eine Sekunde Zeit nehmen und den Link für die von Visual Studio 2010 erstellten * .SDF-Dateien zur Liste der Dateien hinzufügen, die wahrscheinlich nicht zur Versionskontrolle hinzugefügt werden sollten ( Die IDE erstellt sie neu. Da ich nicht sicher war, ob eine * .sdf-Datei an anderer Stelle eine legitime Verwendung haben könnte, habe ich nur die spezifische [Projektname] .sdf-Datei von SVN ignoriert.

Warum erstellt der Visual Studio-Konvertierungsassistent 2010 eine umfangreiche SDF-Datenbankdatei?

Nein, Sie sollten sie nicht zur Quellcodeverwaltung hinzufügen, da sie - wie Sie sagten - benutzerspezifisch sind.

SUO (Solution User Options): Zeichnet alle Optionen auf, die Sie möglicherweise mit Ihrer Lösung verknüpfen, sodass sie bei jedem Öffnen Anpassungen vornehmen, die Sie vorgenommen haben.

Die .user-Datei enthält die Benutzeroptionen für das Projekt (während SUO für die Lösung vorgesehen ist) und erweitert den Namen der Projektdatei (z. B. any.csproj.user enthält Benutzereinstellungen für das Projekt any.csproj).

Dies scheint die Meinung von Microsoft zu diesem Thema zu sein:

Hinzufügen (und Bearbeiten) von .suo-Dateien zur Quellcodeverwaltung

Ich weiß nicht, warum Ihr Projekt das DebuggingWorkingDirectory in der suo-Datei speichert. Wenn dies eine benutzerspezifische Einstellung ist, sollten Sie diese im Dateinamen * .proj.user speichern. Wenn diese Einstellung von allen Benutzern gemeinsam genutzt werden kann, die an dem Projekt arbeiten, sollten Sie sie in der Projektdatei selbst speichern.

Denken Sie nicht einmal daran, die Suo-Datei zur Quellcodeverwaltung hinzuzufügen!Die SUO-Datei (Soluton User Options) soll benutzerspezifische Einstellungen enthalten und nicht für Benutzer freigegeben werden, die an derselben Lösung arbeiten. Wenn Sie die suo-Datei in die scc-Datenbank einfügen möchten, weiß ich nicht, welche anderen Dinge in der IDE Sie beschädigen würden, aber aus Sicht der Quellcodeverwaltung werden Sie die scc-Integration von Webprojekten unterbrechen, das verwendete Plugin Lan vs Internet von verschiedenen Benutzern für den VSS-Zugriff, und Sie können sogar dazu führen, dass der scc vollständig unterbrochen wird (der in einer suo-Datei gespeicherte VSS-Datenbankpfad, der möglicherweise für Sie gültig ist, ist möglicherweise für einen anderen Benutzer nicht gültig).

Alin Constantin (MSFT)

Standardmäßig nimmt Microsoft Visual SourceSafe diese Dateien nicht in die Quellcodeverwaltung auf, da es sich um benutzerspezifische Einstellungsdateien handelt. Ich würde diesem Modell folgen, wenn Sie SVN als Quellcodeverwaltung verwenden.

Visual Studio erstellt sie automatisch. Ich empfehle nicht, sie in die Quellcodeverwaltung zu versetzen. Es gab zahlreiche Fälle, in denen die SOU-Datei eines lokalen Entwicklers dazu führte, dass sich VS auf dieser Entwicklerbox unregelmäßig verhielt. Durch Löschen der Datei und anschließendes erneutes Erstellen durch VS wurden die Probleme immer behoben.

Auf der MSDN-Website wird dies eindeutig angegeben

Die Datei mit den Lösungsbenutzeroptionen (.suo) enthält Lösungsoptionen pro Benutzer. Diese Datei sollte nicht in die Quellcodeverwaltung eingecheckt werden .

Daher würde ich sagen, dass es ziemlich sicher ist, diese Dateien zu ignorieren, während Sie Inhalte in Ihre Quellcodeverwaltung einchecken.

Ich würde nicht. Alles, was sich pro "Benutzer" ändern könnte, ist normalerweise nicht gut in der Quellcodeverwaltung. Verzeichnisse .suo, .user, obj / bin

Diese Dateien sind benutzerspezifische Optionen, die von der Lösung selbst unabhängig sein sollten. Visual Studio erstellt nach Bedarf neue, sodass diese nicht in die Quellcodeverwaltung eingecheckt werden müssen. In der Tat wäre es wahrscheinlich besser, dies nicht zu tun, da dies einzelnen Entwicklern ermöglicht, ihre Umgebung nach Belieben anzupassen.

Sie können die .user-Dateien nicht als Quellcodeverwaltung verwenden, da dies benutzerspezifisch ist. Es enthält den Namen des Remote-Computers und anderer benutzerabhängiger Dinge. Es ist eine vcproj-bezogene Datei.

Die .suo-Datei ist eine sln-bezogene Datei und enthält die "Lösungsbenutzeroptionen" (Startprojekt (e), Windows-Position (was angedockt ist und wo, was schwebt) usw.)

Es ist eine Binärdatei, und ich weiß nicht, ob sie etwas "Benutzerbezogenes" enthält.

In unserem Unternehmen nehmen wir diese Dateien nicht unter Quellcodeverwaltung.

Sie enthalten die spezifischen Einstellungen für das Projekt, die normalerweise einem einzelnen Entwickler zugewiesen werden (z. B. das Startprojekt und die Startseite, die beim Debuggen Ihrer Anwendung gestartet werden sollen).

Es ist daher besser, sie nicht zur Versionskontrolle hinzuzufügen, und VS lässt sie neu erstellen, damit jeder Entwickler die gewünschten Einstellungen vornehmen kann.

.user ist die Benutzereinstellung, und ich denke .suo ist die Benutzeroption der Lösung. Sie möchten nicht, dass diese Dateien der Quellcodeverwaltung unterliegen. Sie werden für jeden Benutzer neu erstellt.

Nein.

Ich wollte nur eine kurze Antwort, und es gab keine.

Mit Rational ClearCase lautet die Antwort nein. In der Quellcodeverwaltung sollte nur das Projekt .sln &. * Registriert werden.

Ich kann nicht für andere Anbieter antworten. Wenn ich mich richtig erinnere, sind diese Dateien "benutzerspezifische" Optionen, Ihre Umgebung.

Fügen Sie keine dieser Dateien zur Versionskontrolle hinzu. Diese Dateien werden automatisch mit arbeitsplatzspezifischen Informationen generiert, wenn sie in die Versionskontrolle eingecheckt werden, was zu Problemen an anderen Arbeitsstationen führen kann.

Nein, sie sollten nicht zur Quellcodeverwaltung verpflichtet werden, da es sich um entwickler- / maschinenspezifische lokale Einstellungen handelt.

GitHub verwaltet eine Liste der vorgeschlagenen Dateitypen, die Visual Studio-Benutzer unter https://github.com/github/gitignore/blob/master/VisualStudio.gitignore ignorieren können

Für svn habe ich den folgenden global-ignoreEigenschaftssatz:

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

Wenn Sie Ihre ausführbaren Verzeichnisabhängigkeiten unter ProjectProperties> Debugging> Environment festlegen, werden die Pfade in '.user'-Dateien gespeichert.

Angenommen, ich setze diese Zeichenfolge in das oben genannte Feld: "PATH = C: \ xyz \ bin". So wird sie in der '.user'-Datei gespeichert:

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

Dies hat uns bei der Arbeit in OpenCV sehr geholfen. Wir könnten verschiedene Versionen von OpenCV für verschiedene Projekte verwenden. Ein weiterer Vorteil ist, dass es sehr einfach war, unsere Projekte auf einer neuen Maschine einzurichten. Wir mussten nur die entsprechenden Abhängigkeitsverzeichnisse kopieren. Bei einigen Projekten ziehe ich es vor, die '.user' zur Quellcodeverwaltung hinzuzufügen.

Auch wenn es völlig von Projekten abhängig ist. Sie können einen Anruf nach Ihren Wünschen entgegennehmen.

Wie in anderen Antworten, die beide .suound .usernicht zur Quellcodeverwaltung hinzugefügt werden sollte, da sie Benutzer / maschinenspezifische (BTW sind .suofür neueste Versionen von VS wurde in spezielles temporäres Verzeichnis verschoben.vs , die vollständig von Quellen Kontrolle gehalten werden sollen).

Allerdings , wenn Ihre Anwendung einig Setup - Umgebung erfordert für das Debuggen in VS (sind solche Einstellungen in der Regel in gehaltenen .userDatei), kann es nützlich sein , eine Beispieldatei (Namensgebung wie vorzubereiten .user.SAMPLE) , und fügen Sie die Quellcodeverwaltung für Referenzen.

Anstelle eines fest codierten absoluten Pfads in einer solchen Datei ist es sinnvoll, relative Pfade zu verwenden oder sich auf Umgebungsvariablen zu verlassen, sodass das Beispiel möglicherweise generisch genug ist, um von anderen problemlos wiederverwendet werden zu können.