Arbeiten mit allgemeinen Bibliotheken/Dienstprogrammbibliotheken

Question

In der Firma, für die ich arbeite, haben wir ein „Utility“-Projekt, auf das praktisch jede Anwendung, die wir erstellen, verweist.Es gibt viele Dinge wie NullHelpers, ConfigSettingHelpers, Common ExtensionMethods usw.

Unsere Arbeitsweise besteht darin, dass wir, wenn wir ein neues Projekt erstellen möchten, die neueste Version des Projekts aus der Quellcodeverwaltung abrufen, sie der Projektmappe hinzufügen und dann auf das Projekt von allen neuen Projekten verweisen, die der Projektmappe hinzugefügt werden.

Das hat gut funktioniert, es gab jedoch einige Fälle, in denen Leute „bahnbrechende Änderungen“ am gemeinsamen Projekt vorgenommen haben, die für sie funktionieren, für andere jedoch nicht.

Ich habe darüber nachgedacht, dass wir, anstatt die gemeinsame Bibliothek als Projektreferenz hinzuzufügen, vielleicht damit beginnen sollten, die gemeinsame Bibliothek als eigenständige DLL zu entwickeln und verschiedene Versionen zu veröffentlichen und eine bestimmte Version für ein bestimmtes Projekt auszuwählen, damit Änderungen ohne Risiko vorgenommen werden können zu anderen Projekten über die gemeinsame Bibliothek.

Abgesehen davon bin ich daran interessiert zu sehen, wie andere auf ihre gemeinsamen Bibliotheken verweisen oder diese verwenden.

Answer 1

Genau das machen wir.Wir haben ein Utility-Projekt, das einige nicht projektspezifische nützliche Funktionen bietet.Wir erhöhen die Version manuell (Minor), erstellen das Projekt in der Release-Version, signieren es und legen es an einem freigegebenen Speicherort ab.

Die Leute verwenden dann die spezifische Version des Bibliothek.

Wenn in bestimmten Projekten einige nützliche Methoden implementiert sind, die ihren Weg in das Haupt-Utility-Projekt finden könnten, fügen wir sie einer speziellen Hilfsklasse im Projekt hinzu und markieren sie als mögliche Utility-Kandidaten (einfaches //TODO).Am Ende des Projekts überprüfen wir die Kandidaten und wenn sie dabei bleiben, verschieben wir sie in die Hauptabteilung Bibliothek.

Breaking Changes sind tabu und wir markieren Methoden und Klassen bei Bedarf als [Obsolete].

Aber das spielt keine Rolle, da wir die Version bei jeder Veröffentlichung erhöhen.

Hoffe das hilft.

Answer 2

Wir verwenden Verzweigung in der Quellcodeverwaltung.Jeder verwendet den Hauptzweig, bis er eine Veröffentlichung vornimmt.Wenn sie die Version verzweigen, verzweigen sie auch das Common Utilities-Projekt.

Darüber hinaus verfügt unser Versorgungsprojekt über eigene Unit-Tests.Auf diese Weise können andere Teams wissen, ob sie den Build für andere Teams unterbrechen würden.

Natürlich haben wir immer noch Probleme, wie Sie sie gelegentlich erwähnen.Aber wenn ein Team eine Änderung eincheckt, die den Build eines anderen Teams kaputt macht, bedeutet das normalerweise, dass der Vertrag für diese Methode/dieses Objekt irgendwo gebrochen wurde.Wir betrachten dies als Möglichkeiten, die Gestaltung des Gemeinschaftsversorgungsprojekts zu verbessern ...oder zumindest weitere Unit-Tests zu schreiben :/

Answer 3

Ich hatte das GENAU gleicher Fehler!

Früher habe ich Projektreferenzen verwendet, aber es scheint alles schief zu gehen, wenn, wie Sie sagen, viele Projekte darauf verweisen.

Ich kompiliere jetzt in eine DLL und setze die CopyLocal-Eigenschaft für die DLL-Referenz nach dem ersten Build auf „false“ (andernfalls kann es meiner Meinung nach dazu kommen, dass Unterprojekte überschrieben werden und es einfach zu einem Durcheinander kommt).

Ich denke, theoretisch sollte es wahrscheinlich GAC-fähig sein, aber wenn es sich um ein Problem handelt, das sich stark ändert (wie bei mir), kann dies problematisch werden.