vs2017 Soll ich die Visual Studio.su und.user-Dateien der Quellcodeverwaltung hinzufügen?




vs2017 marketplace (13)

Visual Studio-Lösungen enthalten zwei Arten von versteckten Benutzerdateien. Einer ist die Lösung. .suo Datei, die eine binäre Datei ist. Die andere ist die Projekt- .user Datei, die eine Textdatei ist. Welche Daten enthalten diese Dateien?

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


Dies scheint die Meinung von Microsoft zu diesem Thema zu sein: http://social.msdn.microsoft.com/forums/en-US/vssourcecontrol/thread/dee90d75-d825-4c76-a30f-016eab15ef7f

Ich weiß nicht, warum Ihr Projekt das DebuggingWorkingDirectory in der SUO-Datei speichert. Wenn dies eine benutzerspezifische Einstellung ist, sollten Sie dies im * .proj.user-Dateinamen speichern. Wenn diese Einstellung für alle Benutzer freigegeben ist, die mit dem Projekt arbeiten, sollten Sie sie in der Projektdatei selbst speichern.

Denken Sie nicht einmal daran, die SUO-Datei der Quellcodeverwaltung hinzuzufügen! Die SUO-Datei (soluton user options) enthält benutzerspezifische Einstellungen und sollte nicht für Benutzer freigegeben werden, die an derselben Lösung arbeiten. Wenn Sie die SUO-Datei in der SCC-Datenbank hinzufügen würde, weiß ich nicht, welche anderen Dinge in der IDE Sie brechen würden, aber aus der Sicht der Quellcodeverwaltung brechen Sie die Integration von Webprojekten scc, das verwendete Lan vs Internet-Plugin von verschiedenen Benutzern für den VSS-Zugriff, und Sie könnten sogar bewirken, dass der SCC vollständig unterbrochen wird (der in der SUO-Datei gespeicherte VSS-Datenbankpfad, der für Sie möglicherweise gültig ist, ist möglicherweise für einen anderen Benutzer nicht gültig).

Alin Constantin (MSFT)


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

Daher ist es besser, sie nicht der Versionskontrolle hinzuzufügen, sodass VS sie neu erstellt, sodass jeder Entwickler die gewünschten Einstellungen vornehmen kann.


Andere haben erklärt, warum die *.suo und *.user Dateien unter Quellcodeverwaltung keine gute Idee sind.

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

  1. So werden andere Entwickler nicht mit den Einstellungen eines Entwicklers enden.
  2. Wenn Sie also den Status anzeigen oder Dateien festschreiben, werden diese Dateien die Codebasis nicht durcheinander bringen und neue Dateien verschleiern, die Sie hinzufügen müssen.

Visual Studio erstellt sie automatisch. Ich empfehle nicht, sie in die Quellcodeverwaltung zu stellen. Es gab schon öfters Fälle, in denen die SOU-Datei eines lokalen Entwicklers dazu führte, dass sich VS auf dieser Entwickler-Box unberechenbar verhielt. Durch das Löschen der Datei und das erneute Erstellen von VS wurden die Probleme behoben.


Diese Dateien sind benutzerspezifische Optionen, die unabhängig von der Lösung selbst sein sollten. Visual Studio erstellt bei Bedarf neue, sodass sie nicht in die Quellcodeverwaltung eingecheckt werden müssen. In der Tat wäre es wahrscheinlich besser, dies nicht zu tun, da dies einzelnen Entwicklern erlaubt, ihre Umgebung so anzupassen, wie sie es für richtig halten.


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


Wenn Sie Rational ClearCase verwenden, lautet die Antwort: Nein, nur das .sln &. * -Proj sollte in der Quellcodeverwaltung registriert werden, ich kann nicht für andere Anbieter antworten. Wenn ich mich richtig erinnere, sind diese Dateien "Benutzer" spezifische Optionen, Ihre Umgebung.


Diese Dateien enthalten Benutzereinstellungen, die im Allgemeinen für Ihren Computer spezifisch sind. Daher sollten Sie ihn nicht in SCM einfügen. Außerdem wird VS es fast jedes Mal ändern, wenn Sie es ausführen, daher wird es immer vom SCM als "geändert" markiert. Ich auch nicht, ich bin in einem Projekt mit VS für 2 Jahre und hatte keine Probleme damit. Der einzige kleine Ärger ist, dass die Debug-Parameter (Ausführungspfad, Deployment-Ziel, etc.) in einer dieser Dateien gespeichert sind (weiß nicht welche), wenn Sie also einen Standard für sie haben, können Sie nicht ' Veröffentlichen Sie es über SCM für andere Entwickler, um die gesamte Entwicklungsumgebung "einsatzbereit" zu haben.


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


.user ist die Benutzereinstellungen, und ich denke, .soo ist die Lösung Benutzeroptionen. Sie möchten diese Dateien nicht unter Versionskontrolle; Sie werden für jeden Benutzer neu erstellt.


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

SUO (Lösungsbenutzeroptionen): Zeichnet alle Optionen auf, die Sie mit Ihrer Lösung verknüpfen könnten, sodass bei jedem Öffnen Anpassungen von Ihnen vorgenommen werden.

Die .user-Datei enthält die Benutzeroptionen für das Projekt (während SUO für die Lösung ist) und erweitert den Projektdateinamen (z. B. irgendetwas. Csproj.user enthält Benutzereinstellungen für das Projekt ally.csproj).


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

Hoffe das hilft.


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





ignore