Kürzlich sind wir bei der Arbeit auf ein Problem gestoßen, bei dem wir ein Projekt markiert / verzweigt haben und einige Kompilierungsprobleme aufgrund von DLL- / Projektreferenzen hatten, die auf die alte Ordnerstruktur verweisen.
Wir haben für jedes Projekt einen Ordner 'external bin' erstellt und die referenzierten DLLs in diese Ordner kopiert. Ist dies der beste Weg oder gibt es einen bestimmten Industriestandard, um damit umzugehen?
Antworten:
Ich würde sagen, dass Nuget der beste Weg ist, um mit Abhängigkeiten umzugehen .
nuget kann Versionen verwalten UND die Abhängigkeiten automatisch von Ihrem lokalen Nuget-Server herunterladen.
Es ist ganz einfach, einen lokalen Server zu erstellen / konfigurieren. Erstellen Sie einfach ein neues leeres ASP.NET-Projekt und installieren Sie das nuget-serverNuget-Paket (mit Nuget;).
Das bedeutet auch, dass Sie nicht alle Abhängigkeiten einchecken und / oder ihre Versionen mit TFS verwalten müssen.
Es ist nicht wirklich - Microsoft sagt, dass der beste Weg, um mit Referenzen umzugehen, darin besteht, Ihr Projekt in einer riesigen Lösung zu erstellen. Ja, ich weiß, sie meinen es auch wirklich so.
Das Muster- und Praxisteam hat seine Best Practices in Bezug auf TFS zusammengestellt, dies gilt jedoch für allgemeine Builds. Es gibt drei Arten von Lösungskonfigurationen, die "1 große Lösung", ein partitionierter Ansatz, der dem ähnelt, wie die meisten Benutzer Builds verwalten, indem sie nacheinander erstellen und Artefakte in ein gemeinsames Verzeichnis kopieren (was von .NET nicht unterstützt wird) mit einem serverweiten 'Include'- oder' Library'-Pfad zur Referenz) und einem Multiple Solution-Setup, das eine komplexere Version des partitionierten ist.
Man sagt
In general you should:
Use a single solution strategy unless the resulting solution is too large to load into Visual Studio.
Use multiple solutions to create specific views on sub-systems of your application.
Use multiple solutions to reduce the time it takes to load a solution and to reduce build time for developers.Für TFS empfehlen sie, externe Projekte innerhalb Ihres Projekts zu verzweigen, anstatt sich auf die Arbeitsbereichszuordnung zu verlassen, die eher den externen Projekten von Subversion ähnelt. Persönlich denke ich, dass ihre Ratschläge dort keine bewährten Methoden sind, aber ich nehme an, dass sie versuchen, alle Build-Probleme zu minimieren, die bei der Verwendung von Referenzen auftreten.
Ich hatte Probleme mit .NET-Builds, die versuchen, das System zu verkürzen, indem nur das erstellt wird, was benötigt wird. Ein nächtlicher Build, der alles erledigt und jede neue Assembly in ein Verzeichnis kopiert, war die beste Möglichkeit für alle, synchron zu bleiben - insbesondere für die Tester. Beachten Sie, dass dies wirklich nur für .NET-Apps gilt. C ++ - Apps funktionieren normalerweise immer noch, da sie keine versionierten Assemblys oder ähnliche Aspekte haben, die Probleme beim Aufrufen von Komponenten verursachen können. Dieser Ansatz funktioniert gut, aber Sie können nicht immer davon ausgehen, dass teilweise Builds in Ordnung sind. Das Dampfen des Ganzen und das Wiederherstellen sind am sichersten.
Dies hängt davon ab, wie Ihre Lösung strukturiert ist und welche Funktionen Ihre Versionskontrollsoftware bietet. Zuvor haben wir in unseren Lösungen ein nicht erstelltes / übersprungenes Projekt beibehalten, das Dokumentation und einen Ordner speziell für Bibliotheken enthält, auf die von Drittanbietern verwiesen wird. Da dies Teil der Lösung war, konnte der Pfad zu diesen Dateien über den relativen Pfad referenziert werden. Nachdem wir zu TFS 2010 gewechselt waren, haben wir dieses Projekt entfernt und einfach ein "Support" -Verzeichnis im Ordner dieser Lösung im Teamprojekt parallel zu unseren Hauptzweigen hinzugefügt. In beiden Fällen befindet sich die Versionsverwaltungsversion der Bibliothek relativ am selben Ort, unabhängig davon, wie die Entwickler ihre Computer konfiguriert haben.
Wenn Sie Subversion zur Versionskontrolle verwenden, können Sie zu diesem Zweck die Eigenschaft "externals" verwenden. Auf diese Weise können Sie eine lokale Kopie einer gemeinsam genutzten DLL in einem relativen Pfad in der Nähe Ihres aktuellen Projekts aufbewahren. Das macht es einfach, diese DLL durch einen relativen Dateipfad zu referenzieren, der sich nicht ändert, selbst wenn Sie das Hauptverzeichnis Ihres Projekts in einen anderen Ordner ändern. Mit Externen können Sie auch definieren, welche spezifische Version oder Revision eingeschlossen werden soll.