Kernbibliotheken zusammenfügen

Question

Vor etwa einem Jahr hat unsere Firma ein relativ großes Softwarepaket erstellt, das hauptsächlich von zwei erfahrenen Entwicklern geschrieben wurde. Zur Vereinfachung der Demonstration werde ich es "Projekt A" nennen. Seitdem haben wir an einem neuen Softwarepaket gearbeitet, "Projekt B" und in seinem Baum ist ein Zweig von Projekt A.

Projekt B hat einen Verweis auf Projekt A, aber jetzt, wo wir uns dem Ende nähern von Projekt B müssen wir auch B von A referenzieren. Also, nach dem Zusammenführen der Zweige von A und bevor wir mit B live gehen, möchten wir die Kernbibliotheken zwischen den beiden Projekten zusammenführen.

Welche Erfahrungen haben Sie mit dieser Art von Situation gemacht? Welche Best Practices und Lektionen wurden bei diesem Projekt gelernt? Wie können wir die Kernbibliotheken mit minimalen Auswirkungen auf den Rest des Quellcodes in Projekt A zusammenführen?

EDIT: Was ist Ihre Meinung über die Durchführbarkeit Projekt A Namespaces beizubehalten, aber den Code in Projekt B-Kernbibliothek Ortung (die letztlich die Kernbibliothek des Unternehmens werden wird)? Von dort Referenz gerade die neue Firma Kern-Bibliothek in den Legacy-Projekten ...

EDIT 2: Danke für die Antworten. Vielleicht ist ein bisschen mehr technische Klärung in Ordnung. Beide dieser Projekte sind sehr eng verwandt, aber jedes hat sein eigenes .NET-Klassenbibliotheksprojekt für eine Kernbibliothek. Darüber hinaus wird jede Bibliothek von anderen verschiedenen .NET-Projekten referenziert. Interne und externe Web Apps, Forms Apps, etc. Meine Frage ist mehr, wo der Quellcode leben sollte - ich glaube nicht, dass sie zwei separate .NET-Projekte bleiben sollten, aber ein einzelnes Projekt enthält beides, wobei die vorhandenen Namespaces zunächst beibehalten werden . Während wir uns weiterentwickeln, werden wir neu gestalten, Namespaces kombinieren, doppelte Funktionalität beseitigen usw. Es gibt keine Zweifel, dass Funktionalität in beiden existierenden Bibliotheken für zukünftige Projekte nützlich sein wird, und es gibt auch eine wachsende Notwendigkeit, zwischen beiden existierenden zu teilen "Kern" -Bibliotheken.

Answer 1

Ist Ihr Problem mit der Möglichkeit der zyklischen Referenzen zwischen B und A?

Oder mehr über widersprüchliche Namespaces zwischen A und B.A?

Wenn sowohl A als auch B.A im selben Namespace (A) im selben Projekt sind, könnte es zu ernsthaften Konflikten kommen.

Eine Möglichkeit besteht darin, beiden Bibliotheken ein Namespacepräfix hinzuzufügen, und je nachdem, welches Sie möchten, können Sie dieses importieren?

dh

A wird V1.P und BA wird V2.A (unter Projekt B)

Also, wenn Sie wollen V1 Sie nur das V1-Namensraum importieren, wenn Sie V2 möchten Sie die V2 importieren Namensraum und die Referenzen sollten in einer Reihe stehen, denke ich?

Sie werden immer noch einige Probleme haben, denn wenn Sie sich mit dem Namespace für A anlegen, werden Sie jeden Legacy Code, der ihn bereits als A und nicht als V1.A bezeichnet, durchbrechen.

Ehrlich denke ich in einem Projekt Ihre Assemblys und Namespaces müssen nur einzigartig sein. Wenn Sie also zwei Versionen von Assemblys mit demselben Namespace haben, muss einer von ihnen gehen.

Answer 2

Ich denke, dies hängt stark von Sprache, Umgebung und Typ der Bibliotheken (dynamisch/statisch verknüpft) ab. Welche Probleme erwarten Sie?

• kollidieren Identifikatoren
• doppelte Funktionalität
• Änderungen an den Build-Prozess
• Integration/Unit-Tests