Laden...

Debuggen von Projekten mit langen Buildzeiten

Erstellt von JimStark vor 3 Jahren Letzter Beitrag vor 3 Jahren 950 Views
JimStark Themenstarter:in
309 Beiträge seit 2020
vor 3 Jahren
Debuggen von Projekten mit langen Buildzeiten

Hi Leute,

angenommen ein Entwickler will eine DLL erweitern (z.B. Projekt.Data.Analysis), der Build der gesamten Anwendung und Programmstart wäre aber zu aufwendig und zu lange dafür (soll nur über Jenkinsserver gebaut weden).
Wie baut man sich dafür eine "Debugging Umgebung" in der Praxis?
Per NUnit Unittest und das dann so gleich testen oder macht man ein extra Projekt für solche Sachen?

Viele Grüße

2.078 Beiträge seit 2012
vor 3 Jahren

Verstehe ich das richtig:
Du willst nicht bauen, aber Du trotzdem debuggen?

Kurz: Geht nicht.
Zumindest würde es mich sehr wundern, wenn doch

Du kannst einen alten Build debuggen, indem Du ihn startest und den Debugger aus VisualStudio anhängst.
Allerdings wirst Du dabei auch auf Schwierigkeiten stoßen, da der Compiler optimiert und spätestens, wenn der Code nicht zum Build passt, wird's spannend.

Ich hab mir für einen ähnlichen Fall mal eine kleine Test-Anwendung gebaut.
Im Code hab ich mir dann die Dialoge zusammengesteckt, die ich gebraucht habe und der Rest blieb weg.
Das geht natürlich nicht immer, in dem Fall nur, weil die Dialoge an sich unabhängig voneinander waren und ich einfach den Großteil davon raus werfen konnte.

Mein Favorit wäre aber eine z.B. modulare Architektur mit guter UnitTest-Abdeckung, denn deren Sinn ist ja gerade, nur den kleinen Teil ohne ewig viele Abhängigkeiten zu testen.

Ansonsten kannst Du auch auf Tools wie DnSpy zurückgreifen.
Damit kannst Du die fertig gebaute DLLs dekompilieren, debuggen und ggf. auch bearbeiten.
Sowas wie Quellcodeverwaltung fällt dann natürlich weg bzw. Du musst die Änderungen immer auf beiden Seiten machen.

JimStark Themenstarter:in
309 Beiträge seit 2020
vor 3 Jahren

Verstehe ich das richtig:
Du willst nicht bauen, aber Du trotzdem debuggen?

Kurz: Geht nicht.

Doch, aber ich will nur das bauen was notwendig ist.

Die Projektmappe besteht z.B. aus:
Projekt.Data.Models
Projekt.Data.Service
Projekt.Data.Analyser
Projekt.Core.License
Projekt.WebApp
...

das ist schon ziemlich Schichtenbasiert aufgebaut, also Analyser hat zum Beispiel nur Abhängigkeiten zu Models, usw.
Wie wird in der Praxis vorgegangen wenn das Projekt extrem groß ist und ich den Analyser erweitern und nicht für jedesmal testen die komplette Applikation neu bauen will.
Ein NUnit Projekt für jede Library oder kann ich die DLLs auch irgendwie Konsolenmäßig nur die jeweiligen Funktionen testen?
Ich schätze mal Unittests wie du gesagt hast ist da das Mittel der Wahl oder?

2.078 Beiträge seit 2012
vor 3 Jahren

Naja, eine Schichtenarchitektur heißt nicht zwangsläufig, dass sie auch gut testbar ist, deshalb schrieb ich ja "modular".

Du hast dann einzelne kleine Module, die unabhängig funktionsfähig sind, die Abhängigkeiten sind z.B. Interfaces, die von einem anderen Modul implementiert werden müssen. Die komplette Anwendung hat Zugriff auf alle notwendigen Module und kann dann die Implementierungen bereitstellen, die UnitTests haben geeignete Mock-Implementierungen dafür.
Wie genau Du das machst, dafür gibt es keine Fausregel.

Aber Du kannst einzelne Projekte bauen, ohne die ganzen Abhängigkeiten ebenfalls zu bauen.
https://stackoverflow.com/questions/3587842/how-to-build-a-c-sharp-project-without-checking-dependencies
Selber hab ich das aber noch nicht gemacht, daher kann ich dazu nichts sagen - laut der ersten Antwort hat das aber auch Nachteile.

16.806 Beiträge seit 2008
vor 3 Jahren

Der einzig valide Weg, das zu lösen, ist das Auslagern von Solution-Bausteinen in NuGet Pakete.
zB den Analyzer in eine eigenes Repository packen, den isoliert bauen und deployen.

Dadurch wird der Analyzer aus der Build Collection der Solution heraus genommen und nicht erneut gebaut, da eben die Assembly referenziert wird.
Das steigert aber natürlich die Komplexität zur Entwicklungszeit, sodass sich das bei kleinen Projekten, wo Elemente eben nicht wiederverwendet werden, nicht lohnt.

PS: "Lange Buildzeit" ist relativ.
Eine schlecht organisierte Solution in .NET kann sehr schnell sehr lange zum Builden benötigen.
Gut organisierte Solutions (zB der Source von Windows) sind immens groß; bauen aber in unter 8 Minuten.