Wann sollte man eine Projektreferenz im Gegensatz zu einer Binärreferenz verwenden?

Question

Mein Unternehmen verfügt über eine gemeinsame Codebibliothek, die aus vielen Klassenbibliotheksprojekten sowie unterstützenden Testprojekten besteht.Jedes Klassenbibliotheksprojekt gibt eine einzelne Binärdatei aus, z. B.Company.Common.Serialization.dll.Da wir sowohl die kompilierten, getesteten Binärdateien als auch den Quellcode besitzen, gibt es Debatten darüber, ob unsere konsumierenden Anwendungen Binär- oder Projektreferenzen verwenden sollten.

Einige Argumente für Projektreferenzen:

• Projektverweise würden es Benutzern ermöglichen, den gesamten Lösungscode zu debuggen und anzuzeigen, ohne den Aufwand für das Laden zusätzlicher Projekte/Lösungen.
• Projektverweise würden dabei helfen, mit allgemeinen Komponentenänderungen Schritt zu halten, die im Quellcodeverwaltungssystem vorgenommen werden, da Änderungen ohne die aktive Lösung leicht erkennbar wären.

Einige Argumente für binäre Referenzen:

• Binäre Referenzen würden Lösungen vereinfachen und für schnellere Ladezeiten der Lösungen sorgen.
• Binäre Referenzen würden es Entwicklern ermöglichen, sich auf neuen Code zu konzentrieren, anstatt sich möglicherweise von Code ablenken zu lassen, der bereits gebacken und als stabil erwiesen ist.
• Binäre Referenzen würden uns dazu zwingen, unsere Inhalte angemessen zu dosieren, da wir die gemeinsame Bibliothek genauso verwenden würden, wie es auch für diejenigen außerhalb unserer Organisation erforderlich wäre.
• Da eine binäre Referenz nicht debuggt (eingeschränkt) werden kann, wäre man gezwungen, Probleme zu replizieren und zu beheben, indem man die vorhandenen Testprojekte erweitert, anstatt sie nur im Kontext der nutzenden Anwendung zu testen und zu beheben.
• Binärreferenzen stellen sicher, dass die gleichzeitige Entwicklung des Klassenbibliotheksprojekts keine Auswirkungen auf die nutzende Anwendung hat, da auf eine stabile Version der Binärdatei und nicht auf eine Influx-Version verwiesen wird.Es wäre die Entscheidung des Projektleiters, ob er bei Bedarf eine neuere Version der Komponente integrieren möchte oder nicht.

Welche Richtlinien/Präferenzen verfolgen Sie, wenn es um die Verwendung von Projekt- oder Binärreferenzen geht?

Answer 1

Für mich hört es sich so an, als hätten Sie alle wichtigen Punkte abgedeckt.Wir hatten kürzlich eine ähnliche Diskussion bei der Arbeit und sind noch nicht ganz entschieden.

Eine Sache, die wir uns jedoch angeschaut haben, besteht darin, auf die Binärdateien zu verweisen, um alle Vorteile zu nutzen, die Sie erwähnt haben. Die Binärdateien werden jedoch von einem gemeinsamen Build-System erstellt, bei dem sich der Quellcode an einem gemeinsamen Ort befindet und von allen Entwicklercomputern aus zugänglich ist ( (zumindest wenn sie bei der Arbeit im Netzwerk sitzen), so dass jedes Debugging bei Bedarf tatsächlich in den Bibliothekscode eintauchen kann.

Aus dem gleichen Grund haben wir jedoch auch viele Basisklassen mit entsprechenden Attributen versehen, damit der Debugger sie vollständig überspringt, da dies bei jedem Debugging, das Sie in Ihren eigenen Klassen (auf der Ebene, die Sie entwickeln) durchführen, der Fall wäre nur durch Code aus den Basisbibliotheken erheblich überdimensioniert werden.Auf diese Weise, wenn Sie die Taste drücken Hineinsteigen Durch das Debuggen einer Tastenkombination für eine Bibliotheksklasse gelangen Sie wieder zum nächsten Codeteil auf Ihrer aktuellen Ebene, anstatt sich durch Unmengen an Bibliothekscode wühlen zu müssen.

Grundsätzlich stimme ich Ihren Kommentaren, bewährten Bibliothekscode für den normalen Entwickler außer Sichtweite zu halten, auf jeden Fall (in SO-Begriffen) zu.

Wenn ich außerdem die globale Lösungsdatei lade, die alle Projekte und im Grunde genommen alles enthält, scheint ReSharper 4 eine Art Herzproblem zu haben, da Visual Studio praktisch zum Stillstand kommt.

Answer 2

Meiner Meinung nach besteht das größte Problem bei der Verwendung von Projektreferenzen darin, dass sie den Verbrauchern keine gemeinsame Grundlage für ihre Entwicklung bieten.Ich gehe davon aus, dass sich die Bibliotheken verändern.Wenn dies der Fall ist, erhalten Sie eine leicht reproduzierbare Umgebung, indem Sie sie erstellen und sicherstellen, dass sie versioniert sind.

Wenn Sie dies nicht tun, führt dies dazu, dass Ihr Code auf mysteriöse Weise kaputt geht, wenn sich das referenzierte Projekt ändert.Aber nur auf einigen Maschinen.

Answer 3

Ich neige dazu, gängige Bibliotheken wie diese als Ressourcen von Drittanbietern zu behandeln.Dadurch kann die Bibliothek über eigene Erstellungsprozesse, QS-Tests usw. verfügen.Wenn die Qualitätssicherung (oder wer auch immer) eine Veröffentlichung der Bibliothek „segnet“, wird sie an einen zentralen Ort kopiert, der allen Entwicklern zur Verfügung steht.Es liegt dann an jedem Projekt, zu entscheiden, welche Version der Bibliothek verwendet werden soll, indem die Binärdateien in einen Projektordner kopiert und Binärreferenzen in den Projekten verwendet werden.

Wichtig ist, mit jedem Build der Bibliothek Debug-Symboldateien (pdb) zu erstellen und diese ebenfalls verfügbar zu machen.Die andere Möglichkeit besteht darin, tatsächlich einen lokalen Symbolspeicher in Ihrem Netzwerk zu erstellen und jeden Entwickler diesen Symbolspeicher zu seiner VS-Konfiguration hinzufügen zu lassen.Dies würde es Ihnen ermöglichen, den Code zu debuggen und dennoch die Vorteile der Verwendung von Binärreferenzen zu nutzen.

Was die Vorteile betrifft, die Sie für Projektreferenzen erwähnen, stimme ich Ihrem zweiten Punkt nicht zu.Für mich ist es wichtig, dass die nutzenden Projekte explizit wissen, welche Version der gemeinsamen Bibliothek sie nutzen, und dass sie einen bewussten Schritt unternehmen, um diese Version zu aktualisieren.Dies ist der beste Weg, um sicherzustellen, dass Sie nicht versehentlich Änderungen an der Bibliothek übernehmen, die noch nicht abgeschlossen oder getestet wurden.

Answer 4

Wenn Sie es nicht in Ihrer Lösung haben möchten oder die Möglichkeit haben, Ihre Lösung aufzuteilen, senden Sie die gesamte Bibliotheksausgabe an ein gemeinsames bin-Verzeichnis und verweisen Sie dort darauf.

Ich habe dies getan, um Entwicklern das Öffnen einer kompakten Lösung zu ermöglichen, die nur die Domäne, Tests und Webprojekte enthält.Unsere Win-Services, Silverlight-Inhalte und Web-Control-Bibliotheken befinden sich in separaten Lösungen, die die Projekte enthalten, die Sie benötigen, wenn Sie sich diese ansehen, aber Nant kann alles erstellen.

Answer 5

Ich glaube, bei Ihrer Frage geht es eigentlich darum, wann Projekte in derselben Lösung zusammenpassen.Der Grund dafür ist, dass Projekte in derselben Lösung Projektverweise aufeinander haben sollten und Projekte in unterschiedlichen Lösungen binäre Verweise aufeinander haben sollten.

Ich bin eher der Meinung, dass Lösungen Projekte beinhalten sollten, die eng gemeinsam entwickelt werden.Zum Beispiel Ihre API-Assemblys und Ihre Implementierungen dieser APIs.

Nähe ist jedoch relativ.Ein Designer für eine Anwendung ist per Definition eng mit der App verbunden, Sie möchten den Designer und die Anwendung jedoch nicht in derselben Lösung haben (sofern sie überhaupt komplex sind).Sie möchten den Designer wahrscheinlich für einen Zweig des Programms entwickeln, der in Abständen zusammengeführt wird, die weiter voneinander entfernt sind als bei der normalen täglichen Integration.

Answer 6

Ich denke, wenn das Projekt nicht Teil der Lösung ist, sollte man es nicht dort einschließen ...aber das ist nur meine Meinung

Ich unterteile es kurz nach Konzept