VS.NET: Projektrefs vs. Baugruppenreferenzen

8

Es gibt hier eine Debatte darüber, was besser ist, um unsere gemeinsame Codebasis aus anderen Projekten zu beziehen: nach Projekt oder nach Assembly. Ich bin dafür, das Projekt zu referenzieren, vor allem, weil wir Unit-Tests automatisiert haben, die beweisen, dass der gemeinsame Code das tut, was er braucht.

Der Gedanke vom anderen Lager ist, diese Projekte zu sperren und nur einmal im Monat oder so etwas zu veröffentlichen. Dann erzwingen Sie, dass alle Projekte auf die Assemblys verweisen. Sie denken, dies schützt sie vor der Bereitstellung von nicht getestetem Code. Sie sind "zu beschäftigt", um automatisierte Komponententests zu schreiben und ihre Projekte für eine kontinuierliche Integration zu konfigurieren, und ich habe keinen Einfluss darauf. Konzentrieren Sie sich also nicht auf diesen Aspekt.

Hier sind die Gründe, warum ich mir vorstellen kann, warum Projektreferenzen die bessere Lösung sind. Ich suche auch andere Meinungen.

PROS:

  • Die Referenzierung von Projekten stellt sicher, dass Sie mit dem neuesten Code arbeiten. Sie müssen nicht auf irgendetwas warten.
  • Verringerung der Doppelarbeit. Ohne den neuesten Code zu haben, besteht eine größere Chance, das Rad neu zu erfinden.
  • Wenn ein Entwickler etwas benötigt und es nicht zur Assembly hinzufügen kann, wo es hingehört, wird es an jedem Ort erstellt, an dem es funktioniert, wodurch viele Inkonsistenzen und Codeduplikationen entstehen.
  • Die Entwicklung ist einfacher, da Sie einfach sehen können, was im referenzierten Code passiert.
  • Unser gewöhnliches Zeug ändert sich nicht oft, aber wenn es so ist, ist es normalerweise etwas Nützliches. Warum die zusätzliche Belastung durch die Verwaltung der Verwaltung von Wartung und Montage hinzufügen.

CONS:

  • Kann möglicherweise länger dauern, um zu laden.
  • Das Hinzufügen von Projekten zu einer neuen Lösung und das Hinzufügen von Assembly-Referenzen kann etwas länger dauern.
Corey Coogan 08.01.2010, 16:40
quelle

3 Antworten

4

Hier sind ein paar Profis, die du vermisst hast

  • Live-Aktualisierung: Funktionen wie intellisense werden automatisch zwischen Projekt- und Projektreferenzen aktualisiert, wenn Sie die APIs ändern
  • GoTo Definition: Wenn Sie eine Assembly-Referenz haben, führt Sie GoTo Definition zur eigentlichen Code-Definition. Mit einer Assembly-Referenz gelangen Sie zur generierten Metadatensignatur.
  • Alle Referenzen finden: Verarbeitet den gesamten Code in Projektreferenzen für die Verwendung einer Referenz. Für eine Assembly-Referenz sehen Sie nur Verwendungen innerhalb der Metadaten
  • Schnellsuche (nur 2010): Ähnlich wie alle Referenzen, funktioniert nur besser in einer P2P-Referenz

Als Antwort auf Ihre Nachteile

  • Ja: Das Laden eines Projekts ist in der Regel langsamer als das Laden eines Verweises. Bei einer angemessenen Anzahl von Projekten ist dieser Zeitunterschied jedoch nicht signifikant und sollte sich nicht auf Ihre tägliche Entwicklungsroutine auswirken.
  • Ja: Das Hinzufügen eines Projekts zur Lösung ist im Allgemeinen langsamer als das Hinzufügen einer Referenz. Der Unterschied ist jedoch in Sekunden und kostet einmalig. Ich denke, es ist ein Fehler, dies als Teil der Kriterien zu betrachten.
JaredPar 08.01.2010 16:45
quelle
2

Nun, wenn Sie irgendeine Art von Quellenkontrolle verwenden, könnten Sie beide Lager erfüllen. Verwenden von Verzweigungen oder Beschriftungen (abhängig von Ihrer Quellcodeverwaltung).

Grundsätzlich können Sie, wenn Sie ein Team haben, das Ihren gemeinsamen Code kontrolliert, eine stabile Version abzweigen / kennzeichnen. Dann würden Ihre Projekte die stabile Version verwenden. Dies schützt Sie vor der Bereitstellung von instabilem Code für Ihre anderen Projekte und bietet Ihnen die Möglichkeit, die gesamte Quelle zu testen, zu debuggen und anzuzeigen.

Immer wenn Ihr gemeinsames Steuerelemententeam einen neuen stabilen Build erstellt, können Sie Ihre Quellreferenzen aktualisieren, um sie aus dem neuen Zweig zu ziehen.

Die andere Seite dieses Szenarios ist, dass Sie einen Patch auf den gemeinsamen Code haben könnten, um sich nicht mit den laufenden Entwicklungsbemühungen zu verwirren. Natürlich bringt dies eine zusätzliche Verwaltungslast mit sich, wenn der gemeinsame Code an mehreren Stellen aktualisiert werden muss.

    
Joshua Cauble 08.01.2010 16:47
quelle
0

REFERENZSTRATEGIE IST IMMER EIN GEMEINSAMES PROBLEM

Ich weiß, dass dies eine sehr alte Frage ist, aber es wird immer eine relevante Frage mit relativen Antworten sein und ich erinnere mich, dass ich vor ein paar Jahren die gleiche Frage hatte und die Auswirkungen der beiden Entscheidungen ( Projekt versus Versammlung Referenzen) wurde mir erst in den letzten zwei Jahren bewusst, als ich Vollzeit an einem Builder für ein System mit mehr als 800 Projekten in über 300 Lösungen für eine einzelne WPF-App arbeitete.

PROJEKTREFERENZEN SIND IDEAL FÜR VISUAL STUDIO

Projektreferenzen sind ideal, weil Sie der IDE viel mehr Einblick in die Details Ihres Codes geben, da Sie Visual Studio explizit mitteilen, wo sich das referenzierte Projekt und der gesamte Code befinden. Wenn Sie an einem System mit weniger als 200 Projektmodulen arbeiten und sich nur wenige Lösungen (Projektgruppierungen) leisten können, sollten Sie nach Projektreferenzen suchen, da Visual Studio während der Entwurfszeit mehr für Sie mit diesen zusätzlichen Informationen tun kann der Code anstelle von referenzierten Assemblys.

Assembly-Referenzen können besser skaliert werden

Wenn Ihr System viel größer als 200 Projekte ist, können Ihre Builds sehr langsam werden. Ich habe 20 Minuten pro Build gesehen und das ist wirklich nervig. Wenn Sie also auf eine DLL verweisen können, die sich nicht ändert, weisen Sie Visual Studio "NICHT" an, sie zu erstellen, und das hat offensichtlich einen gewissen Einfluss auf die Zeit für den Build.

REFERENZEN FÜR DIE MONTAGE ERSTELLEN EINE ILLUSION EINES ENTKOPPELTEN SYSTEMS

Projektreferenzen bieten Ihnen eine intelligentere IDE, die immer weiß, wo und an wie vielen Stellen ein Typ verwendet wird, wo der Code gefunden werden kann, und einige andere nützliche Statistiken, da alle Projekte direkt referenziert werden. Es kann Sie auch warnen, wenn Sie versehentlich versucht haben, einen Zirkelverweis zu erstellen.

PROS der Assemblyreferenzen:

  1. Wenn Sie einige Projekte als externe Abhängigkeiten behandeln, können Sie kleinere Lösungen und kleinere Gruppierungen verwandter Projekte erstellen, da nicht verwandte Projekte als externe Assemblys behandelt werden.
  2. Erlaubt Visual Studio sehr gut mit sehr großen, modularisierten Systemen umzugehen.
  3. Zwingt Sie, eine dll / Assembly-Staging-Strategie während des Build-Prozesses auszuarbeiten.

DISADVANTAGEN von Assemblyverweisen:

  • Zirkuläre Referenzen werden möglich und Ihre weniger erfahrenen Entwickler werden diese Referenzen anfangs nicht bemerken.

      

    Sie können diese Herausforderung durch Zirkelverweise umgehen, indem Sie eine Ihrer Assemblys als Baugruppe eines Drittanbieters behandeln, die eingecheckt, zur nächsten Version übertragen und zuletzt erstellt wird. Wenn ein Build für ein Projekt fehlschlägt, das diese ausgeschlossene Assembly verwendet, können Sie beschließen, das benannte Projekt neu zu erstellen, und häufig die Kreisabhängigkeit ausgleichen. (NICHT EMPFOHLEN, aber es ist möglich)

  • Aufwärts gerichtete Framework-Verweise werden ebenfalls möglich, da Sie Verweise auf DLLs hinzufügen, die mit einem höheren .net-Framework kompiliert werden, und Visual Studio gibt Ihnen keine eindeutigen Ursachen-Meldungen, wenn dies geschieht, sodass Sie viele Dinge versuchen, um das Problem zu beheben Problem und scheitern oft, bevor Sie herausfinden, um die Framework-Versionen zu beheben.
      

    Bei neuen Projekten wird standardmäßig die neueste Version des .NET-Frameworks verwendet. Dabei wird nicht berücksichtigt, dass sich alle Projekte in der aktuellen Lösung noch in einer früheren Version von .net befinden. Wenn Sie also eine Referenz zu diesem Projekt hinzufügen, Sie werden oft einen seltsamen Fehler bekommen, der nicht so leicht zu verstehen ist.

  • Verzweigungsverweise werden auch möglich, weil Sie wahrscheinlich in mehr als einer Verzweigung gleichzeitig arbeiten und manchmal beim Hinzufügen einer Referenz verwirrt sind.
      

    Sie klicken auf "Referenz hinzufügen", gehen ein paar Verzeichnisse nach oben, gehen ein paar Verzeichnisse nach unten, wählen die DLL aus und klicken auf Hinzufügen, ohne zu merken, dass die DLL tatsächlich zu weit oben und unten in einem anderen Zweig ist, an dem Sie gerade arbeiten. Dieses Problem wird erst viel später deutlich, wenn der Buildserver versucht, diese Assembly aufzulösen, und fehlschlägt. Und der Fehler "unbekannter Namespace, fehlt Ihnen eine Assembly-Referenz?" wird dir nicht helfen, die Zeit deines ganzen Teams zu verschwenden.

Martin Lottering 28.10.2016 19:35
quelle