Sollte eine SLN zur Quellcodeverwaltung verpflichtet werden?

Ist es eine bewährte Methode, eine SLN-Datei für die Quellcodeverwaltung festzuschreiben? Wann ist dies angemessen oder unangemessen?

Update In den Antworten wurden mehrere gute Punkte hervorgehoben. Danke für die Antworten!

Ich denke, aus den anderen Antworten geht hervor, dass Lösungsdateien nützlich sind und festgeschrieben werden sollten, auch wenn sie nicht für offizielle Builds verwendet werden. Sie sind praktisch für alle, die Visual Studio-Funktionen wie Gehe zu Definition / Deklaration verwenden.

Standardmäßig enthalten sie keine absoluten Pfade oder andere maschinenspezifische Artefakte. (Leider verwalten einige Add-In-Tools diese Eigenschaft nicht ordnungsgemäß, z. B. AMD CodeAnalyst.) Wenn Sie in Ihren Projektdateien (sowohl C ++ als auch C #) relative Pfade verwenden, sind diese maschinenunabhängig auch.

Die wahrscheinlich nützlichere Frage ist: Welche Dateien sollten Sie ausschließen? Hier ist der Inhalt meiner .gitignore-Datei für meine VS 2008-Projekte:

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

(Der letzte Eintrag ist nur für den AMD CodeAnalyst-Profiler.)

Für VS 2010 sollten Sie außerdem Folgendes ausschließen:

ipch/
*.sdf
*.opensdf

Ja - ich denke es ist immer angemessen. Benutzerspezifische Einstellungen befinden sich in anderen Dateien.

Ja, das solltest du tun. Eine Lösungsdatei enthält nur Informationen zur Gesamtstruktur Ihrer Lösung. Die Informationen sind global für die Lösung und werden wahrscheinlich allen Entwicklern in Ihrem Projekt gemeinsam.

Es enthält keine benutzerspezifischen Einstellungen.

Du solltest es auf jeden Fall haben. Neben den Gründen, die andere erwähnt haben, ist es notwendig, einen schrittweisen Aufbau des gesamten Projekts zu ermöglichen.

Ich stimme im Allgemeinen zu, dass Lösungsdateien eingecheckt werden sollten. In der Firma, für die ich arbeite, haben wir jedoch etwas anderes getan. Wir haben ein ziemlich großes Repository und Entwickler arbeiten von Zeit zu Zeit an verschiedenen Teilen des Systems. Um unsere Arbeitsweise zu unterstützen, hätten wir entweder eine große oder mehrere kleinere Lösungsdateien. Beide weisen einige Mängel auf und erfordern manuelle Arbeit seitens der Entwickler. Um dies zu vermeiden, haben wir ein Plug-In erstellt, das all das erledigt.

Mit dem Plug-In kann jeder Entwickler eine Teilmenge des Quellbaums auschecken, um daran zu arbeiten, indem er einfach die relevanten Projekte aus dem Repository auswählt. Das Plugin generiert dann eine Lösungsdatei und ändert die Projektdateien im laufenden Betrieb für die angegebene Lösung. Es behandelt auch Referenzen. Mit anderen Worten, der Entwickler muss lediglich die entsprechenden Projekte auswählen und anschließend die erforderlichen Dateien generieren / ändern. Auf diese Weise können wir auch verschiedene andere Einstellungen anpassen, um Unternehmensstandards sicherzustellen.

Zusätzlich verwenden wir das Plug-In, um verschiedene Check-In-Richtlinien zu unterstützen, die im Allgemeinen verhindern, dass Benutzer fehlerhaften / nicht konformen Code an das Repository senden.

Ja, Dinge, die Sie begehen sollten, sind:

• Lösung (* .sln),
• Projektdateien,
• alle Quelldateien,
• App-Konfigurationsdateien
• Skripte erstellen

Dinge, die Sie nicht begehen sollten , sind:

• Lösungsbenutzeroptionen (.suo) Dateien,
• Generierte Dateien erstellen (z. B. mithilfe eines Build-Skripts) [Bearbeiten:] - nur, wenn alle erforderlichen Build-Skripte und -Tools unter Versionskontrolle verfügbar sind (um sicherzustellen, dass Builds im Lebenslaufverlauf authentisch sind).

In Bezug auf andere automatisch generierte Dateien gibt es einen separaten Thread .

Ja, es sollte Teil der Quellcodeverwaltung sein. Wann immer Sie Projekte zu Ihrer Anwendung hinzufügen oder daraus entfernen, wird .sln aktualisiert und es wäre gut, es unter Quellcodeverwaltung zu haben. Es würde Ihnen ermöglichen, Ihre Anwendungscode 2-Versionen zurück zu ziehen und direkt einen Build durchzuführen (falls überhaupt erforderlich).

In den meisten Fällen empfiehlt es sich, SLN-Dateien für die Quellcodeverwaltung zu übernehmen.

Wenn Ihre SLN-Dateien von einem anderen Tool (z. B. CMake) generiert werden, ist es wahrscheinlich unangemessen, sie in die Quellcodeverwaltung zu übernehmen.

Ja, Sie möchten immer die SLN-Datei einschließen. Sie enthält die Links zu allen Projekten, die in der Lösung enthalten sind.

Wir tun es, weil es alles synchron hält. Alle notwendigen Projekte befinden sich zusammen und niemand muss sich Sorgen machen, dass eines fehlt. Unser Build-Server (Ant Hill Pro) verwendet auch die SLN, um herauszufinden, welche Projekte für eine Version erstellt werden sollen.

Normalerweise legen wir alle unsere Lösungsdateien in einem Lösungsverzeichnis ab. Auf diese Weise trennen wir die Lösung ein wenig vom Code, und es ist einfacher, das Projekt auszuwählen, an dem ich arbeiten muss.

Der einzige Fall, in dem Sie sogar in Betracht ziehen würden, es nicht in der Quellcodeverwaltung zu speichern, wäre, wenn Sie eine große Lösung mit vielen Projekten in der Quellcodeverwaltung hätten und für einige eine kleine Lösung mit einigen der Projekte aus der Hauptlösung erstellen möchten private vorübergehende Anforderung.

Ja - Alles, was zur Generierung Ihres Produkts verwendet wird, sollte sich in der Quellcodeverwaltung befinden.

Wir speichern oder lösen Dateien in TFS Version Control. Da die Hauptlösung jedoch sehr groß ist, haben die meisten Entwickler eine persönliche Lösung, die nur das enthält, was sie benötigen. Die Hauptlösungsdatei wird hauptsächlich vom Build-Server verwendet.

.slns sind das einzige, mit dem wir in tfs keine Probleme hatten!