Was ist der beste Weg, um mit geteilten DLLs in C# umzugehen?

Question

In meinem Team haben wir Hunderte von freigegebenen DLLs, die auch auf andere DLLs verweisen, die wiederum auf andere DLLs verweisen, und so weiter. Wir haben begonnen, ein "Shared" -Verzeichnis für alle dlls zu verwenden, von denen wir denken, dass sie generisch genug sind, um sie in anderen Projekten zu verwenden, wie zum Beispiel einer Datenbank-Comms-DLL.

Das Problem ist, dass, wenn eine der DLLs den ganzen Weg hinunter der Baum geändert wird, dann alles, das es referenziert, neu kompiliert werden muss, um Versionierungsprobleme zu vermeiden (die zur Laufzeit auftreten).

Um dies zu vermeiden, ist jetzt die Rede davon, all unsere "gemeinsamen" DLLs in eine große Assembly zu integrieren, und jeder, der neue Apps erstellt, referenziert dies einfach und das alleine.

Dies wird natürlich immer größer und ich bin mir nicht sicher, ob das der beste Weg ist oder nicht. Irgendwelche Gedanken bitte?

Answer 1

Es ist definitiv nicht der beste Weg, es zu tun. Ich habe ein paar "shared" DLLs in meinem Job, die so ähnlich sind. Sie werden unhandlich und schwierig (lese: unmöglich), um sinnvolle Änderungen vorzunehmen, weil es zu schwierig wird, sicherzustellen, dass Änderungen Apps nicht downstream beschädigen, was genau das Gegenteil von dem zu sein scheint, was Sie versuchen zu tun.

Es klingt wie, was Sie wirklich tun müssen, trennt Ihre Sorgen ein wenig besser. Wenn sich alle diese DLLs gegenseitig referenzieren, sind sie wahrscheinlich zu eng gekoppelt. Eine echte "geteilte" DLL sollte eigenständig oder als Teil eines Pakets aus drei oder vier Gruppen, die sich als Gruppe bewegen, stehen können. Wenn Ihre Abhängigkeiten tatsächlich verhindern, dass Sie Änderungen vornehmen, ist Ihre Kopplungsstrategie furchtbar falsch.

Alles in eine große DLL zu stecken wird sicherlich nichts besseres machen. In der Tat, wahrscheinlich das Gegenteil. Sobald Sie alles in einer DLL haben, ist die Versuchung da, alles noch enger miteinander zu verbinden, was es später unmöglich macht, Dinge auseinander zu ziehen.

Answer 2

Wir behandeln die Wartung der freigegebenen DLLs als ein Projekt für sich, mit einer eigenen Quellcodeverwaltung und allem. Dann veröffentlichen wir etwa zweimal im Jahr die freigegebenen DLLs für die Öffentlichkeit, mit einer eigenen Versionsnummer und allem. Solange Sie die DLLs immer als 'Set' verwenden (dh alle, die Sie referenzieren, stammen aus derselben Version), haben Sie garantiert keine Abhängigkeitsprobleme.

Answer 3

können Sie eine Lösung machen, die alle verbundenen Projekte enthalten.
und wenn Sie freigeben müssen, bauen gerade diese Lösung

---

aktualisieren.
Wie Sie sagen, die Lösung kann nicht so viel dlls halten.
In anderen Seite können Sie ein externes MSBuild Skript oder mit CruiseControl.NET machen, die Möglichkeiten zu machen, so komplizierte Aufgaben.

Answer 4

Um aus dem GoF Buch zu zitieren, "Programm zu einer Schnittstelle, keine Implementierung." Dies könnte hier für einige Ihrer Bibliotheken gelten. Sie wissen bereits, wie spröde Ihre Entwicklung wird, wenn Sie eine enge Kopplung haben. Was nun angesprochen werden muss, ist, wie man Ihnen Raum zum Atmen gibt.

Sie können eine Schnittstelle erstellen. Dies stellt einen Vertrag bereit, den jede Anwendung verwenden kann, um anzugeben, dass ein Mindestsatz an Funktionalität verfügbar ist.

Sie können einen Service erstellen, der eine Schnittstelle implementiert. Dies ermöglicht es Ihnen, etwas bereitzustellen, was als Addon oder Plugin gedacht wäre. Dies ermöglicht Ihnen, auf eine Vertragsversion mit Erwartungen zu reagieren, die Ihre Tools einhalten.

Sie können einen Dienst erstellen, der nur eine Schnittstelle verwendet. Dadurch kann Ihre Anwendung eine konkrete Implementierung senden, die einem Designvertrag entspricht.

Produkte wie Entwicklungseditoren und Webbrowser verwenden diesen Ansatz, um eine Wiederverwendung von Code zu ermöglichen. Vielen Dank. Schönen Tag.

Design Principles from Design Patterns

Plugin