C# Fragen zum managen von mehreren Projekten in einer Solution

  • Allgemein

Es gibt 15 Antworten in diesem Thema. Der letzte Beitrag () ist von DTF.

    C# Fragen zum managen von mehreren Projekten in einer Solution

    Hallo,
    ich programmiere sehr viel C# aber kenne mich mit dem build up Prozess nicht so gut aus.
    Aktuell habe ich aufgrund logischer Trennung und dem versuch der Modularisierung über 400 Projekte in meiner Solution. Dabei ist zu sagen, dass zu jedem erstellten Projekt ein UnitTest Projekt gehört (und ab und zu noch eine integration Test Projekt)
    Das bauen der Solution und das durchlaufen aller Tests dauert entprechend lange.
    Würde es das bauen deutlich beschleunigen, wenn ich die Projekte mehr zusammenziehe und die logische Trennung innerhalb eines Projektes mache? (Also statt 400 Projekte nur noch 200 aber dafür deutlich größere Projekte)
    Gibt es dazu eine Faustregel oder "Best practice" Ansätze, wann man ein neues Projekt hinzufügen sollte und wann nicht?

    @Martell Willkommen im Forum. :thumbup:
    400 Projekte in der Solution ist pauschal gesagt ein NoGo.
    Du hast doch keinen Überblick mehr über den Inhalt Deiner verstreuten Projekte.
    Vielleicht sagst Du mal was darüber, nach welchen Kriterien Du ein neues Projekt erstellst / hinzufügst und wie groß Deine einzelnen Projekte sind.
    ====
    Bei mir kommen Solutions mit 20 Projekten vor.
    Eine Projekt-Gliederung bei mir sieht etwa so aus:
    - GUI
    - Interfaces
    - Kamera Hersteller 1
    - Kamera Hersteller 2
    - Laser
    - Mathematik
    - ...
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Danke für das Willkommen. ^^
    Ja so ist eigentlich auch in meiner Solution die Aufteilung. Ich muss dazu sagen es ist eine Solution für mehrere Maschinentypen die zum Teil viel gemeinsam haben.
    Z.B. Hat Maschine A ein Kamerasystem X und Maschine B hat das Kamerasystem Y.
    Dazu die Projektaufteilung:

    - KameraCommon --> beinhaltet alle Gemeinsamkeiten
    - KameraCommonTest --> Unit Tests
    - KameraCommonIntegrationTest

    - KameraMaschineA --> beinhaltet Eigenheiten des Systems X
    - KameraMaschineATest --> Unit Tests
    - KameraMaschineAIntegrationTest

    - KameraMaschineB --> beinhaltet Eigenheiten des Systems Y
    - KameraMaschineBTest --> Unit Tests
    - KameraMaschineBIntegrationTest

    Dabei ist erstmal davon auszugehen das eine Maschine immer nur mit einen Kamerasystem arbeiten kann.

    Diese Aufteilung zieht sich dann so durch die ganze Solution für alles mögliche. Natürlich gibts es keine maschineneigene Projekte wenn alles gleich ist.

    Weitere Projektbeispiele:
    - CanCommunication
    - OPCUAConnection
    - Laser
    - Calibration
    - Heater
    - ....

    Die allgemeinen Projektaufteilungen sind denk ich schon ok. Aber wäre es z.B. sinnvoll, statt ein Testprojekt für jedes einzelne Projekt nur ein Testprojekt zu haben wo alle Tests drin sind? Oder die "Common" und spezifischen Projekte vielleicht in eins zu packen und die Aufteilung über eine Ordnerstruktur zu realisieren? Mir wäre vor allem wichtig zu wissen, ob ich dadurch einen Vorteil habe. Also z.B. dass das bauen deutlich schneller geht oder so (ich will das ungern Umbauen, wenn ich am Ende nichts davon habe XD )

    Tests zusammen zu legen halte ich für nicht gut.
    Ein Projekt und das dazugehörige Testprojekt.
    Nicht ein Testprojekt für zwei ... n Projekte.
    ====
    Ich kann meine Kameras austauschen. Dem Gerät ist es egal, welche Kamera angeschlossen ist.
    Die Auswahl selbst erfolgt per Settings, das ist einfacher, als zu testen, welche Kamera kommuniziert.
    Ansonsten läuft die Hardware-Kommunikation immer über Interfaces, das sichert,
    dass eine neue Hardware sehr schnell eine andere ersetzen kann.
    Und ich habe alle Interfaces in einer DLL.
    ====
    Kann es sein, dass Du mit Deinem Software-Komplex verschiedene Maschinen ansteuerst, die nix miteinander zu tun haben,
    nur um sie in einer einzigen Projektmappe zu haben?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Das ist nicht ganz einfach zu beantworten. Die Maschinen sind ganz einfach ausgedrückt große Drucker.
    Die unterschiedlichen Maschinen arbeiten nicht zusammen. Die bestehen aber zum Großteil aus den gleichen Bausteinen.
    Die Idee dahinter war einen Baukasten zu haben mit dem ich softwareseitig ganz schnell eine neue Maschine betriebsbereit bekomme.
    Hätte ich eine Solution für eine Maschine, hätte ich halt sehr viel Code Dopplung und das wollte ich vermeiden. Z.B. wenn es einen Defekt in einer Maschine gibt, muss ich das meistens nur an einer stelle fixen anstatt für jede Maschine in jeder Solution.
    Aber ich bin dabei keinem vorgefertigten Konzept gefolgt, sondern hab mir einfach die Vor und Nachteile dazu überlegt und dann entschieden. Also kann gut sein, dass esfür sowas ein deutlich besseres Konzept gibt, dass ich hätte benutzen sollen :saint:

    Hi.

    Bei den Tests würde ich ein Test-Projekt mit Unterordnern für die jeweiligen Testtypen anlegen.

    Quellcode

    1. Tests/
    2. + UnitTests
    3. + ...
    4. + EndeToEndTests


    Ein Test-Projekt pro Anwendungsprojekt.

    Mir stellt sich die Frage, warum ein Projekt pro Kamera.
    Ich würde diese logisch zusammenfassen als Kameras, und darin einfach diese als Geräte-Klasse definieren.


    - KameraCommon --> beinhaltet alle Gemeinsamkeiten
    - KameraCommonTest --> Unit Tests
    - KameraCommonIntegrationTest

    - KameraMaschineA --> beinhaltet Eigenheiten des Systems X
    - KameraMaschineATest --> Unit Tests
    - KameraMaschineAIntegrationTest

    - KameraMaschineB --> beinhaltet Eigenheiten des Systems Y
    - KameraMaschineBTest --> Unit Tests
    - KameraMaschineBIntegrationTest


    Ich hätte das dann so ausgelegt. Mit HasA und IsA, anstatt das in Projekten aufzuteilen.
    Geräte.Kamera.Typ.Hersteller.Modell
    Maschinen.Maschine.Kameras
    Kamera.Tests


    @RodFromGermany Wie cool ist das denn, Interfacesegregation sogar auf Datei-Ebene. Ich habe immer geglaubt, dass Segregation nur meint, wie die Klassen ihre Methoden implementieren müssen.

    So ich mach mal uns ' nen Kaffee, das wird wieder eine Grundsatzdiskussion... lol :* ?( :love: 8| :thumbup: :thumbsup:

    c.u. Joshi aus HH

    @Joshi Die Kameras sind 3rd Party, sie bringen ihre eigenen Installationen und DLLs mit.
    Die Interfaces sorgen dafür, dass ich sie als Black Box behandeln kann.
    Je nach dem, welche Kamera der Kunde bekommt, bekommt er nur diese Installation und somit keine Kenntnis von den anderen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Ich nochmal mit etwas mehr Kaffee ... Joshi.HasACoffee != Joshi.NeedsACoffe.Except().IsDefault().OderSo()

    Danke für die Aufklärung, also sind die Kameras als Software-Pakete zu verstehen, somit ist dann eine Trennung in Projekten ratsam.
    Wozu haben wir denn USB und überhaupt ... :S

    Und dann kommt das Strategie-Muster zum Einsatz?
    "Dieser Premiumkunde, bekommt die Güldene-Kamera und die Schischi-Treiber. Nee, der ist nur Free-To-Play und bekommt nur das aus dem Ordner 'der Geräähht'."

    Dann folgt auf HasA und IsA = BezahltÄ :saint:

    c.u. Joshi Apropos Laser und Kameras. Was für 'ne James-Bond-Villain-Sache läuft hier eigentlich? Wenn jemand fragt, ich war nie hier ...

    @Joshi Das war schon ein tricky Projekt. Spezielle Kameras mit 5-stelligen Preisen, die gezielt manipuliert wurden.
    Der Unterschied zwischen den Kameras bestand in der Pixelgröße, Ziel war der Test der Eignung der Manipulation für medizinische Zwecke.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Aber würde ein Build/Rebuild deutlich schneller gehen wenn es nur 200 statt 400 Projekte sind (ohne weitere Optimierungen ). Ich denke da an Reduzierung des Overheads, weil jedes Projekt hat ja seine eigene Referenztabelle. Oder geht das eigentlich so schnell, das man den Unterschied dann nicht merken würde? (aktuell dauert ein rebuild mit VS22 ca 15 min)

    Du kannst auch einfach nur ein einzelnes Projekt kompileren. Mach mal einen Klick mit rechts im Solutionexplorer auf ein Projekt und schau mal was dir alles gezeigt wird.
    Aber so viele Projekte in einer Mappe ist zu viel. Ich hab selbst recht große Projekte, aber auf mehr als auf 10 Projekte in einer Mappe, bin ich noch nie gekommen.
    Zitat von mir 2023:
    Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

    Ich stelle mir die Frage, ob es eine Option wäre, mittels Plugin-System eine Trennung der Solution zu ermöglichen. Also eigenständige DLL-Projekte, die ein gemeinsames Interface für das Hauptprogramm zur Verfügung stellen, das Hauptprogramm lädt bei Programmstart all diese DLLs und ruft sie quasi generisch auf. Klar, ich kenn das Projekt nicht und weiß daher nicht, ob es infrage kommt.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    hm.... stimmt. Eigentlich macht man ja eher selten einen Rebuild. Bei den 400 Projekten sollte das bauen pro Projekt ja schneller gehen, wenn sie nicht so groß sind. Und wenn ich was neues einbaue oder was umarbeite, bin ich meist nur in 4 oder 5 Projekten unterwegs. Also könnte sich die Bauzeiten vermutlich sogar verlängern, wenn es deutlich größere Projekte sind, die mitgebaut werden müssten, oder? :)

    Ja, richtig. Eine Komplettkompilierung ist immer ein Großaufwand. Und wenn nur ein kleines Projekt geändert wird, reicht es, dieses neu zu kompilieren.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Du kannst auch vor oder nach dem Build Scripte ausführen. Da nutze ich oft xcopy. Du kannst aber auch einen gemeinsamen Ausgabeordner festlegen. Beschäftige dich mal mit den Einstellungen vom Studio, also Zwischenverzeichniss, Ausgabeverzeichniss und auch mit Pre- und Post- Build Aufgaben.
    Zitat von mir 2023:
    Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

Facebook
Telefonspende