Project folder structure vs dotnet-ef tooling

[georg-jung]

Ich hab das da ja rein beschrieben, weil ich mir was dabei gedacht habe. Wenn Du es rausnimmst, macht das den Gedanken hinter der Struktur des Repos/Projektverzeichnisses kaputt. Wenn das zu einem Problem führt, lass uns besser das Problem lösen, als die Ordnerstruktur so zu organisieren, wie es die Auskommentierung tut (Intermediate-Dateien bei Code, Build Dateien gesondert).

Grundsätzlich ist das Ändern des BaseIntermediateOutputPath durchaus Linux-kompatibel.

[autoit4you]

Siehe tests. Somit ist die änderung nicht linux-kompatibel.

[autoit4you]

Das Problem ist nicht, dass das Grundsätzlich nicht Linux-Kompatibel ist, sondern das die Linux-Version von der EF-CLI das nicht unterstützt.

[georg-jung]

Ahso. Das zugrundeliegende Problem kommt aus dem Gebiet: dotnet/efcore#18060

Man kann nur entweder dotnet-ef verwenden oder den BaseIntermediateOutputPath ändern. Vielleicht behebt sich das mit EF Core 7: dotnet/efcore#23853

Ich hatte das Problem nicht, weil ich die EF Core Werkzeuge in Visual Studio verwendet habe: https://docs.microsoft.com/en-us/ef/core/cli/powershell

Unterm Strich sind wir also heute gezwungen, aus einer von zwei suboptimalen Lösungen zu wählen:

1. Nettere Projektordnerstruktur (Status Quo prä diese Woche)
   • Alle Build Outputs liegen in ./obj/<Project> und ./bin/<Project>, was manuelles Aufräumen und Artifact sammeln leicht macht
   • Visual Studio EF Core Tooling geht problemlos, CLI Tooling dotnet ef geht nur, wenn man zeitweise die Änderung vornimmt, um die es in diesem PR geht und anschließend manuell die entstandenen obj-Ordner wegwirft.
2. Einfach funktionierendes dotnet-ef tooling
   • Alle Build Outputs liegen in ./<Project>/obj und ./<Project>/bin, was Build Outputs überall in die Source Code Verzeichnisse verstreut
   • CLI Tooling geht einfach so

Abwägung

• Erstellen von DB Migrationen ist hoffentlich selten, Build Outputs liegen jeden Tag wo sie liegen.
• (2) ist leichter zu verstehen, weil Dinge "einfach gehen" und die Build Outputs zwar verstreut aber dort liegen, wo viele .Net Entwickler suchen würden.
• Der Vorteil von (2) kommt hauptsächlich zum Tragen, wenn man darauf angewiesen ist, nicht die Visual Studio Package Manager Console zu nutzen. Also wenn man
  • kein Visual Studio hat oder
  • das EF Tooling in Scripts nutzen will

Der aktuelle Stand, ohne den PR, quasi "Weg 3"

• Nur finale Build Outputs umgeleitet, Intermediates nicht
• Finale Build Outputs liegen in ./bin/<Project>, Intermediates in ./<Project>/obj
• Contra: Damit ist die Ordnerstruktur total chaotisch
• Pro: Sammeln der finalen Outputs für Artifacts simpel, alles an Tooling funktioniert "einfach so", Kombination der Vorteile?

Mein Fazit: Wenn ich jetzt alleine hieran arbeiten würde, würde ich vermutlich Weg (1) gehen, da mir Weg (2) einen Komfort gibt, den ich nicht brauche. In unserem größeren Bild könnten aber die Vorteile von Weg (2) überwiegen.

Bauchgefühle? /cc @Delphinator

[georg-jung]

Ist aber eine nicht wirklich drängende Abwägung. Können wir uns ja überlegen, wenn wir eh zum Thema zusammensitzen.

Fänd nur toll, wenn wir hier passabel aufschreiben, warum wir sowas ändern, wenn wir es mal tun. Auch, damit wir es selbst später noch verstehen.

[autoit4you]

Eine Sache die ich noch hinzufügen möchte: Ich hatte auch probiert die Build-Intermediates in einen gesammelten Ordner ohne Projektspezifischen Unterordner zu legen. Das hatte zumindest zu dem Zeitpunkt recht flaky. Vielleicht geht das auch irgendwie ohne das es flaky ist?

[georg-jung]

Naja, das tut ja genau die Einstellung, die dafür sorgt, dass das dotnet-ef Tool nicht mehr funktioniert. Der Weg um die Intermediates umzuleiten ist genau die Zeile, die dieser PR ändert.

Aktuell geht - EF Core-seitig - nur:

• Intermediates umleiten
• ODER dotnet-ef Tool nutzen

Es gibt noch ein paar Unterfälle und Mischformen, die für uns nicht greifbar relevant sind. Wenns dich interessiert kann ichs bei Gelegenheit erzählen. Oder du guckst in die Issues, die ich oben verlinkt hab.

[JensGutermuth]

Baugefühl ist, dass ihr euch beide sehr viel mehr auseinandergesetzt habt. Aus dem Bauch heraus klingt es, als ob der von @georg-jung vorgeschlagene "Weg 2" in allen Varianten funktioniert, aber halt Build Outputs überall verteilt. In CI und auf Entwicklungsrechnern unterschiedliche Ordnerstrukturen zu haben erscheint mir verwirrend, deshalb... ist der "Weg 2" am einfachsten verständlich? Manuelles Aufräumen lässt sich ggf. mit einem Skript lösen?

[autoit4you]

Man kann nur entweder dotnet-ef verwenden oder den BaseIntermediateOutputPath ändern. Vielleicht behebt sich das mit EF Core 7: dotnet/efcore#23853

Dies wurde für EF 7 nun gecuttet

[georg-jung]

Hmm, schade. Hab mal gefragt. Mal sehen was bei rum kommt.