Wie organisieren Sie Open-Source-Visual Studio-Projekte mit Open-Source-Abhängigkeiten?

Question

Ich habe ein Open-Source-MVC4-Projekt gestartet, das ein anderes Open-Source-Projekt als Abhängigkeit verwendet. Ich habe das andere Projekt gegabelt und werde es an meine Bedürfnisse anpassen. Das Problem, dem ich gegenüberstehe, ist, wie man diese Projekte voneinander abhängig hält, aber getrennt verwaltet. Aber Leute, die mein Projekt ziehen, würden auch das Abhängigkeitsprojekt bekommen?

1. Ich kann den gesamten Code aus einem anderen Projekt in mein Repository knallen, aber auf diese Weise kann ich nicht zu einer Verzweigung eines abhängigen Projekts beitragen. Ich werde nur ein Teil meines Repositories werden. Ich will das nicht wirklich machen.
2. Ich kann andere Projekte komplett separat verwalten und * .dll-Dateien in mein Projekt kopieren. Und bind abhängige DLL-Dateien in git. Das ist nett, aber ich verliere die Fähigkeit, zwei Projekte zur gleichen Zeit zu entwickeln, zusammen mit abhängigen Code beim Debugging (na ja, vielleicht nicht, wenn * .pdb Dateien kopieren)
3. Ähnlich wie Punkt 2, kann ich Nuget bauen Pakete von abhängigen Projekt und fügen Sie sie zu meinem Hauptprojekt - wieder kann nicht beide Projekte zur gleichen Zeit wirklich entwickeln, müssen Kontexte wechseln.
4. Mit etwas Magie haben eine Lösung Datei, die Projekte aus meinem Repository und abhängigen Repository kombiniert. Kopieren Sie bei jedem Build abhängige DLL-Dateien in den/lib-Ordner und übernehmen Sie sie. Auf diese Weise muss ich den Kontext zwischen einzelnen Projekten nicht wechseln. Aber der Nachteil ist, wenn andere Mitwirkende mein Projekt ziehen, bekommen sie kein abhängiges Projekt, und Lösungsdateien werden wahrscheinlich für sie kaputt gehen, weil es ein Projekt referenziert, das nicht im Repo ist.

Wie organisieren Sie Ihren Code in diesem Fall?

Answer 1

Normalerweise verwende ich nuget für alle meine Abhängigkeiten. Wenn ich ein Projekt forkiere, werde ich es auf nugget und auch auf symbol source bereitstellen. Auf diese Weise können Sie ohne Probleme in die Abhängigkeitsquelle treten.

Weitere Informationen zu Symbolquelle und nuget siehe auch: Creating and Publishing a Symbol Package. Um das Debuggen von Symbolquellen zu aktivieren, siehe http://www.symbolsource.org/Public/Home/VisualStudio.

Sie müssen auch daran denken, Nuget package restore zu aktivieren.

Mit dieser Lösung können Sie Quellcode nicht ändern, aber zumindest können Sie es debuggen.

Answer 2

Falls Sie nicht zirkuläre Abhängigkeiten, schaffen ist folgende Idee:

1. ein neues Class Library Projekt mit einem eindeutigen Namen, sagt ClassLibrary1, zu der Lösung

2. in der hinzufügen Build Seite seiner Projekteinstellungen, Config Output path zu Anwendung Ausgabepfad

3. in der Build Events Seite, fügen Sie die folgende Zeile zu Post-build event command line Block:

   del "$(TargetPath)" 
   

4. Wiederholen Sie Schritt 1 bis 3, aber einen anderen Namen zu geben, sagen ClassLibrary2 und Config Output path zum Quellpfad von ClassLibrary1

5. Set Project Dependancies von ClassLibrary1, überprüfen Sie auf ClassLibrary2

6. alle anderen Projekt als Referenzprojekt hinzufügen zu ClassLibrary2, lassen Copy Local mit Standardwert true

7. build ClassLibrary2 einmal, und alle DLLs sind nun im Quellpfad von ClassLibrary1

8. fügen Sie sie zu den Referenzen von ClassLibrary1 und lassen Copy Local mit Standardwert true

9. Set Project Dependancies der Anwendung und alle anderen Projekte, die nicht Ursache sind kreisförmige Abhängigkeiten, zu überprüfen ClassLibrary1

10. Referenzen von anderen Projekten hinzufügen, von dem Pfad der DLLs in ClassLibrary1 gestellt wurden

11. Copy Local all diesen hinzugefügt DLLs in anderen Projekten auf false

So das Projekt ClassLibrary1 eine zentrale Kontrolle der externen Bibliotheken Ihrer Lösung sein. Jedes Mal, wenn Sie Rebuild Solution (oder nur die Anwendung erstellen), kopiert ClassLibrary1 die neuesten DLLs zu seinen Verweisen auf den Anwendungsausgabeordner und löscht die DLL, die es selbst generiert mit dem Namen ClassLibrary1.DLL. Die Anwendung und die Abhängigkeiten zur Kompilierzeit oder zur Laufzeit verwenden dieselbe Version der DLLs. Sie müssen nicht jede Implementierung einzeln bereitstellen oder überprüfen.

Answer 3

Ich verwende etwas ähnliches im Konzept zu CMake, aber vollständig innerhalb von Visual Studio. Es gibt das relativ unbekannte Merkmal von Eigenschaftendateien, die von Lösungen aufgenommen werden können. Auf diese Weise können Sie eine Datei erstellen, die nur Pfade zu Abhängigkeiten enthält, die Bibliotheken einschließen und relative Pfade festlegen und dann festlegen, dass Benutzer die entsprechenden Pfade für die anderen Abhängigkeiten festlegen müssen, die Sie nicht einschließen können/wollen.

Mit ein wenig Arbeit, es kommt ziemlich sauber, und ist super einfach zu automatisieren durch TeamCity und andere ähnliche Werkzeuge (jeder Build-Agent kann die Variablen setzen, um anzuzeigen, wo es Abhängigkeiten hält).

Für kleine Abhängigkeiten und solche, die optimiert wurden, um mit meinem Projekt zu arbeiten, behalte ich ein Archiv oder die losen Dateien im Repository und verwende die Eigenschaftendatei, um diese zu referenzieren. Andere haben Anweisungen, wo sie zu finden sind und wie sie die Pfade bearbeiten können.

Wenn Sie in einem solchen Ansatz interessiert sind, kann ich etwas mehr ins Detail gehen. Es hat ein bisschen Arbeit gekostet, das herauszufinden, da Property-Dateien nicht sehr gut dokumentiert sind, aber ziemlich gut funktionieren.