Visual Studio: Reihenfolge zufällig erstellen?

8

Ich habe eine Lösung mit 239 Projekten. Ich habe momentan folgendes Problem:

Wenn ich nach der vollständigen Bereinigung (Löschen des Ausgabeverzeichnisses) ein "Alles neu erstellen" in der Lösung mache:

%Vor%

Ich verstehe Folgendes:

  • Visual Studio ist Multithreading der Zusammenstellung (in meinem Fall 4 Assembly gleichzeitig)
  • Ich habe keine explizite "Projektabhängigkeit" angegeben (Rechtsklick auf Lösung - & gt; Projektabhängigkeiten)

Was ich nicht verstehe

  • In diesem Beispiel ist AAA ein referenziertes Projekt von BBB, für mich ist es eine implizite Abhängigkeit, wie wäre es möglich, BBB korrekt zu erstellen, ohne sicher zu sein, dass AAA korrekt erstellt wurde?
  • Wie sollen wir das schaffen für eine Lösung, die 239 Projekte macht? Es ist schwer genug, sicherzustellen, dass wir uns nicht auf ein falsches Projekt beziehen. Wenn wir also immer die Bauaufträge sicherstellen müssen, wird es kompliziert.

Eine einzige Notiz: Ich weiß nicht, ob dies auf eine kürzliche Änderung (eines Projekts / Visual Studios / ...) zurückzuführen ist, weil ich 2 Jahre lang an dieser Lösung arbeite und es das erste Mal ist Ich bin diesem Thema immer wieder begegnet.

Also die Frage:

  1. Gibt es eine Möglichkeit, dies zu handhaben, ohne dass jede Projektabhängigkeit für die Lösung angegeben werden muss?
  2. Wenn nicht, wie sollen wir das machen?

BEARBEITEN Nach dem Kommentar finden Sie hier einige Zusatzinfos:

  • Es gibt keine Kompilierungsfehler in AAA oder BBB, außer dass die Referenz
  • nicht gefunden werden kann
  • Wir verweisen auf Projekte und nicht auf dll (geprüft in einem bestimmten Fall, in dem ich den Fehler hatte.

In BBB.csproj habe ich die folgende Referenz:

%Vor%

BEARBEITEN 2 Ich weiß nicht, ob das direkt damit zusammenhängt, aber beim Überprüfen der Projektabhängigkeiten stellte ich fest, dass BBB abhängig von CCC ist (aber für AAA ist nichts angegeben. Ich frage mich, ob es eine Abhängigkeit gibt , im Grunde ignoriert es alle Informationen aus den Referenzen? Wenn ich versuche, die CCC Abhängigkeit zu entfernen, bekam ich eine Nachricht: This dependency was added by the project system and cannot be removed

EDIT 3

Ich habe eine interessante Entdeckung gemacht: Der Fehler, den ich in EDIT 2 habe, liegt darin, dass diese Abhängigkeit beim Erstellen der Referenz zwischen den beiden Projekten hinzugefügt wurde.

Aus einem unbekannten Grund scheint diese Abhängigkeit für eine Referenz hier nicht erstellt worden zu sein. Wenn ich die Projektreferenz lösche, dann füge ich die Referenz wieder demselben Projekt hinzu, jetzt habe ich diese Abhängigkeit (die ich nicht löschen kann). Ich kann nicht finden, wo diese "Abhängigkeit gespeichert ist. Irgendeine Idee, wie man diese Lösung weit "repariert"?

    
J4N 27.04.2015, 15:08
quelle

4 Antworten

2

Nach einigen Nachforschungen fand ich das Problem:

Tatsächlich sollte Visual Studio automatisch diese Abhängigkeiten zwischen den Projekten hinzufügen, wenn man eine in ein Projekt verweist. Ich kann das sehr einfach sehen, indem ich einfach einen Projektverweis hinzufüge. Außerdem scheinen diese "Abhängigkeiten" nicht entfernt zu werden (siehe meine Bearbeitung 2).

Die Frage, die ich gestellt habe, ist also, wie kann ich einige Projekte referenzieren und keine Abhängigkeit für einige Projekte?

Ich habe überprüft, dass meine Referenzen (zumindest in einigen Fällen sah ich, dass es nicht funktionierte) und sie waren Projektreferenz und nicht DLL.

Einige meiner Kollegen mit dem exakt gleichen Code (Holen Sie die neueste Version des Codes ohne Änderungen) hatten dieses Problem nicht und die Abhängigkeit wurde in Visual Studio angezeigt.

Also habe ich die Datei *.sdf in der Nähe meiner Lösungsdatei entfernt (nachdem ich Visual Studio geschlossen habe). Ich habe wieder geöffnet und Tadaa, alle Abhängigkeiten wurden von Visual Studio neu berechnet. Jetzt baue ich alles neu, alles ist direkt ein Erfolg.

Ich bin nicht sicher, warum es passiert, ich hatte etwas Zeit, um Visual Studio zu töten, vielleicht war etwas dann beschädigt.

    
J4N 28.04.2015, 04:54
quelle
2

Von deinem Post hast du das gesagt "I've no explicit "Project Dependency" specify(Right click on solution -> Project Dependencies)" Dies bedeutet, dass alle Ihre Referenzen auf die kompilierten DLLs und nicht auf die Projekte verweisen.

Ich habe diesen Ansatz oft von Teams mit großen Lösungen gesehen (Sie haben 239 Projekte), aufgrund der Langsamkeit von VS, um so viele Projektreferenzen zu laden.

Die Problemumgehungen, die ich gesehen habe, sind:

  • Mehrere Lösungen für jeden Teilbereich der primären Lösung, z. B. Entitäten, DAL, Logik, Service usw.
  • Einchecken von DLLs (nicht empfohlen, aber ich habe es gesehen) in Source, um für schnellere Builds verwendet zu werden. Sobald Sie einen Codebereich ändern, sind Sie dafür verantwortlich, die DLL zu ersetzen.
  • Konfigurieren der Projektabhängigkeiten-Einstellungen, damit die Builds in der richtigen Reihenfolge ausgeführt werden.
  • Umgang mit der Leistung der Projektreferenzen (langsam, aber sicherstellend Build-Reihenfolge

Eine einzige Lösung mit 239 Projekten scheint dem Grundsatz zu widersprechen, Ihre Entwicklung in kleinere Module aufzuteilen, aber das ist nicht immer Ihre Entscheidung ...

    
Martin Noreke 27.04.2015 18:38
quelle
0

Ich habe dieses Problem in einer kleineren, aber stark voneinander abhängigen Lösung gesehen. Wir haben dieses Problem gelöst, indem wir die maximale Anzahl paralleler Projekt-Builds verringert haben, bis sie vorhersehbar erfolgreich sind. Werkzeuge - & gt; Optionen - & gt; Projekte und Lösungen - & gt; Erstellen und Ausführen.

    
AWinkle 27.04.2015 18:47
quelle
0

Ich weiß, dass dies keine Lösung ist, aber Sie könnten Ihre Kompilierungsabhängigkeiten in Laufzeitabhängigkeiten umwandeln, wenn Sie Dependency-Injection-Technologien wie MEF oder Unity verwenden.

In diesem Fall haben Ihre Projekte begrenzte Abhängigkeiten (Schnittstellen, Container).

Aber ich muss sagen, dass diese Technologien einige Nebenwirkungen haben - wie "pseudozufällige" Initialisierung und so weiter ...

    
sac1 28.04.2015 05:24
quelle

Tags und Links