Wir bauen eine .NET-Softwareplattform für die Testautomatisierung für den internen Gebrauch in unserem Unternehmen.
Die Anwendung besteht aus einer GUI (WinForms) -Komponente und verschiedenen "Aktionen", die dynamisch in sie geladen werden, um ausgeführt zu werden.
Es laufen bereits ca. 100 Action-Projekte mit steigender Anzahl. Einige dieser Projekte sind von anderen Projekten abhängig usw.
Alle geladenen Aktionen müssen auf unsere SDK-DLL für verschiedene Aktivitäten verweisen (Ergebnisse zur Hauptanwendung, Protokollierung usw.).
Mit diesem relativ einfachen Design stehen wir vor einigen Managemententscheidungen, die wir am besten lösen möchten:
Was ist die beste Lösung für so etwas? und warum?
Was sind gängige Praktiken in Szenarien, in denen eine Vielzahl von miteinander verbundenen Projekten verwaltet wird? Gibt es irgendwelche Tipps dafür?
Dies ist ein Problem, das keine klare Antwort hat, aber ...
Es gibt zwei Wege, die du nehmen kannst. Ein stark gekoppeltes System oder ein lose gekoppeltes System.
Für ein stark gekoppeltes System kann ich zwei Verzeichnisse für Binaries vorschlagen: ein Verzeichnis eines Drittanbieters und ein Verzeichnis, das DLLs enthält, die von Ihren Firmen erstellt werden, auf die andere Entwickler verweisen können. Die Drittanbieter-DLLs (außerhalb Ihres Unternehmens) sollten sich in der Quellcodeverwaltung befinden, sodass alle Entwickler dieselben Versionen der Drittanbieter-DLLs vom selben Speicherort referenzieren, wodurch Entwickler-Inkonsistenzen vermieden werden und die Software von Drittanbietern auf jedem Computer installiert werden kann. Die internen DLLs sollten nicht in der Quellcodeverwaltung referenziert werden und sollten auf jedem Entwicklungscomputer über eine automatisierte Build-Batch-Datei oder ähnliches erstellt werden. In einem Build-Post-Schritt können Sie sie alle in das gleiche Verzeichnis kopieren. Solange Entwickler die neueste Quellcodeverwaltung und -erstellung erhalten, hat jeder die gleichen DLLs in Ihrer Firma.
Beispiel: Holen Sie sich die neueste Version, erstellen Sie (mithilfe einer Batch-Datei alle erforderlichen Projekte), und kopieren Sie dann als Post-Build-Schritt die Ausgabe in common. Jetzt können alle Ihre anderen Projekte auf die allgemeinen Compnay-DLLs und die DLLs von Drittanbietern vom selben Speicherort verweisen und alle sind konsistent.
Das Problem ist, dass die Referenzen stark gekoppelt sind, so dass Änderungen manchmal problematisch sein können, wenn sie nicht richtig kommuniziert werden.
Ein lose gekoppeltes System verwendet ein Framework wie MEF (Managed Extensibility Framework) und Ihre Komponentenreferenz "Contract DLL", die die Schnittstellen für Ihre Komponenten definieren. Das Projekt referenziert die Interface- oder Vertrags-DLLs und kümmert sich nicht wirklich um die Implementierung und dann verwaltet MEF das Plugin für Sie.
In diesem Fall verweisen Sie auf die Schnittstellen-DLL, nicht aber auf die eigentliche DLL, die implementiert.
Beispiel: Ich habe eine Schnittstelle namens ILog mit einer Methode namens LogMessage.
%Vor%In einem stark gekoppelten Fall: Action.DLL verweist direkt auf Logger.DLL.
In einem locker gekoppelten Fall verweist Action.DLL auf ILog.DLL (nur die Schnittstelle). Logger.DLL implementiert ILog.DLL. Aber Action.DLL hat keinen direkten Bezug auf Logger.DLL.
Jetzt kann ich eine beliebige Anzahl von DLLs haben, die die ILog-Schnittstelle betreffen, aber die Action.DLL referenziert sie nicht direkt. Das ist ziemlich cool und eine der aufregendsten Eigenschaften von MEF und losen Kopplung im Allgemeinen, die Fähigkeit, keine Abhängigkeiten zu haben.
Wie Sie sich entscheiden, auf jeden Fall zu gehen, ist akzeptabel. Ich denke, die lose gekoppelte Idee passt am besten zu Ihrem Szenario, da die Teams nur die Verträge im Vergleich zu den tatsächlichen Implementierungen kennen müssen.
Ich hätte keine riesige Vertrags-DLL, ich würde versuchen, die Schnittstellen in logische Gruppierungen zu zerlegen. Zum Beispiel scheint die Protokollierung wie ein Utility-Interfance-Typ zu sein, also würde ich eine Utility-Vertrags-DLL mit einer ILog-Schnittstelle erstellen. Wie es aufgeteilt wird, hängt davon ab, was Sie versuchen zu tun. Oder jede Schnittstelle könnte eine Vertrags-DLL sein, aber vielleicht ist das ein bisschen extrem.
Dies ist ein etwas komplexes Thema, besonders in .NET Land. Ich kenne keine "beste" Lösung, aber ich erkläre, wie wir es schaffen; vielleicht wirst du es für dich nützlich finden.
Dies ermöglicht es Ihnen, große Systeme mit vielen verknüpften Projekten zu erstellen, die jedoch mit vielen Komplexitätsproblemen verbunden sind. Wie ich denke, jede Lösung dieser Art würde.
Erstens: physische Struktur (wir verwenden SVN).
Ihr Ordner versioned \ build enthält Build-Skripte, um beispielsweise Binärdateien von Efeu zu erhalten, Ihr Projekt nach Efeu zu veröffentlichen oder jedes Projekt zu kompilieren. Sie werden auch nützlich sein, wenn Sie einen Continuous Integration-Server auf jedes Ihrer Projekte zeigen möchten.
Zweitens: Definieren, wo Abhängigkeiten von
kommenAntwort: Sie kommen von Ihrem Efeu-Repository (es könnte so einfach wie ein Netzwerk-Shared-Dateisystem sein). Sie haben Ihr Repository erstellt, damit Sie die Kontrolle über seinen Inhalt haben. Seien Sie sehr vorsichtig mit Drittanbieter-Binärdateien, die im GAC installiert werden. Visual Studio ist ein Schmerz in der A ^^, um damit umzugehen.
Speziell:
Wie überprüft man alles, was benötigt wird? Abhängigkeiten (Bibliotheken von Drittanbietern für Beispiel) sind in der Tat aus der richtigen Ort?
Ivy gibt Ihnen eine große Flexibilität mit Abhängigkeiten und behebt auch transitive Abhängigkeiten; zB können Sie sich auf SDK rev="1. +" status="latest.release" verlassen, was "die neueste stabile Version 1.x des SDK oder SDK rev=" 2. + "status=" bedeutet. Integration ", was die neueste verfügbare Binärdatei des 2.x SDK bedeuten würde (wahrscheinlich wie aus einem Continuous Integration Build erzeugt).
Sie werden also immer auf kompilierte Binärdateien angewiesen sein, nie auf die Projektausgabe. Und Sie können steuern, welche Version der Binärdateien zu bekommen. Abhängigkeiten von Drittanbietern werden wahrscheinlich als transitiv auf Ihr SDK angewendet.
Dies bedeutet auch, dass die Menge an Code in Ihren Projekten so klein bleibt, wie Sie brauchbare Visual Studio-Lösungen benötigen. Es bedeutet auch, dass Refactoring-Tools wie ReSharper viel weniger nützlich sein werden. Es wird auch eine gewisse Komplexität in Bezug auf Ihre Build-Skripte und Ihre Verzweigungsstrategie geben. Das hängt sehr von der Logik Ihrer Komponenten ab.
Dies ist ein kurzer Überblick, wenn Sie denken, dass dies die Art von Sache ist, die Sie wollen, kann ich die Antwort erweitern. Viel Glück; Das .NET-Ökosystem und insbesondere Visual Studio wird nicht wirklich so funktionieren.