Liebe Forenmitglieder,

ich programmiere mir gerade eine lustige kleine Applikation. Mir fällt unangenehm auf, daß die .exe - Datei, die mir Visual Studio da erstellt, mit ihren knapp über 12 MB doch etwas groß erscheint.

Mein vorheriges Projekt war ein sehr mächtiges Tool mit sehr vielen Features und schlappen 40.000 Zeilen mehr Code. Die Exe - Datei von diesem Projekt ist schlanke 435 K groß.

Die einzigen (so far) Verweise sind auf die Microsoft.Xaml.Behaviors und die Prism.WPF und Prism Core. Das ist denke ich mal nicht der Grund dafür. Ich habe die Projekteigenschaften dieser beiden Projekten verglichen, aber keinen Unterschied feststellen können.

Noch kurz zu den Eckdaten:

Ich verwende VS2022, das Zielframework ist das .NET Framework 4.8

Hat jemand eine Idee?

Eilt aber nicht.

Ich hab gerade eine WPF Anwendung mit 4.8 und Microsoft.Xaml.Behaviors, Prism.WPF und Prism Core erstellt, sonst nichts.
Der Debug-Build ist unter 2 MB groß.

Das Problem liegt also in deinem eigenen Code, hast Du große Dateien als embedded Resource, ein Haufen Bilder oder besondere Einstellungen?

Und Du solltest auf das neue .NET umsteigen - macht vieles deutlich einfacher.
Z.B. ist die csproj-Datei *deutlich* übersichtlicher.

Hallöchen Palladin.

Zunächst einmal Dankeschön für Deine schnelle Antwort.

Ich habe nur ganz wenige, kleine Resourcen eingebettet. Das sind ein paar Icons und ein paar Fonts - das war's.

Zitat

Ich hab gerade eine WPF Anwendung mit 4.8 und Microsoft.Xaml.Behaviors, Prism.WPF und Prism Core erstellt, sonst nichts. Der Debug-Build ist unter 2 MB groß.

Auch ich hab grad mal ein solches Projekt erstellt. Da ist die exe grad mal süße 8K "groß".

Zitat

Und Du solltest auf das neue .NET umsteigen - macht vieles deutlich einfacher. Z.B. ist die csproj-Datei *deutlich* übersichtlicher.

Das hat einen bestimmten Grund: Die Geräte auf denen das Progrämmchen laufen soll, sind meistens sehr alt und meistens nicht mit dem Internet verbunden. Mein kleines Testgerät hier wollte die - zum Glück testhalber schnell erstellte - .net Anwendung nicht starten. Deswegen bin ich zähneknirschend auf Framework 4.8 zurück. Da läuft das Vorgängermodel meines Programmes wunderbar drauf.

Zitat von Sindelfinger

Ich habe nur ganz wenige, kleine Resourcen eingebettet. Das sind ein paar Icons und ein paar Fonts - das war's.

Wenn es keine Resourcen sind, ist es etwas anderes, aber das kannst nur Du sehen.
Vielleicht hast Du nicht alle Resourcen auf dem Schirm? Dekompiliere doch mal mit ILSpy und schau dir an, was der dir für Resourcen anzeigt.
Oder natürlich irgendwelche schrägen Einstellungen.

Ohne mehr Infos führt das hier aber zu nichts.
Wirf doch mal so lange Inhalte raus, bis Du einen deutlichen Größenunterschied sehen kannst.
Dann kennst Du die Ursache oder zumindest einen Teil davon.

Zitat von Sindelfinger

Mein kleines Testgerät hier wollte die - zum Glück testhalber schnell erstellte - .net Anwendung nicht starten.

.NET muss natürlich installiert sein, alt und neu sind nicht kompatibel - hast Du das bedacht?
Wenn das Installieren von .NET nicht in Frage kommt, kannst Du mit der "self-contained"-Option auch Runtime + Framework mit liefern, dann wird das Ergebnis natürlich deutlich größer, aber mit anderen Funktionen kann man da wieder viel reduzieren.

Application publishing - .NET
Installieren von .NET unter Windows - .NET
core/supported-os.md at main · dotnet/core (Und die anderen Versionen - schau im Pfad)

12 MB ist keine "Riesengroße EXE Datei" - daher habe ich den Titel in was sinnvolles umbenannt.

Kurz zu den Basics: die Größe einer Exe-Datei hat keinerlei Aussagekraft, wenn man das Setup nicht kennt.
Es gibt gewisse Parameter, die dafür sorgen, dass eine Exe größer wird; einfaches Beispiel: man kann Runtime-Optimierungen in den Build verlagern. Das sorgt dafür, dass die Anwendung schneller startet, dafür aber größer ist; irgendwo müssen die Optimierungen abgelegt werden.
Genauso kann man beim Kompiliervorgang gewisser Runtimes bestimmen, dass zB ein Teil der .NET Runtime in die Exe eingebettet wird, sodass man unabhängiger vom PC/Server/Whatever ist.

Nur weil also die Exe von App A kleiner ist als B hat das genau 0 Aussagekraft. Man kann auch keine nativ entwickelten Apps (C) mit Apps vergleichen, die auf einer Managed Runtime basieren (Java, .NET...), weil das völlig verschiedene Ausgangssituationen sind.
Die maximale Größe eine Exe-Datei unter Windows kann aktuell 4 GB betragen.

Die aktuelle Trim-Size einer .NET Console App als Single File Build beträgt ca. 10 MB.
Trimming options - .NET
Create a single file for application deployment - .NET
Das ist für eine Runtime, wie sie .NET ist, vergleichweise klein.

Bei der Doku des Assemblies Aufbaus von .NET wird das auch klar:
> .NET assembly file format
> PE Format - Win32 apps
Das kann also niemals mit etwas verglichen werden, das 200 K hat.

Zitat

Mein vorheriges Projekt war ein sehr mächtiges Tool mit sehr vielen Features und schlappen 40.000 Zeilen mehr Code. Die Exe - Datei von diesem Projekt ist schlanke 435 K groß.

Und das ist mit Sicherheit keine .NET Anwendung oder vergleichbar (Java..). Selbst für eine native Anwendung unter C ist das relativ klein.

Auch Anzahl von Code-Zeilen hat hier genau 0 Aussagekraft. Steht in 0 Verhältnis zur End-Größe einer erstellten Exe.
Das Forum hier ist ein Hobby-Projekt, viele NuGet Pakete und trotzdem weit über 75.000 Zeilen Code: Calculate code metrics - Visual Studio (Windows)
- Lines of Code hängt enorm von der Sprache, dem Programmierstil und den Guides ab; in C# kann ich eine Klasse mit einer Zeile Code erstellen, oder aber auch mit unendlich vielen Zeilen (Stichwort Records).
- Lines of Executable Code ist Abhängig vom eingesetzten Compiler

@Abt:
Soweit ich weiß sind die genannten Build-Funktionen für .NET 4.8 nicht verfügbar, oder?
Demnach fällt hier auch der Single File Build raus, da es hier ja um .NET 4.8 geht.

Korrekt. Deswegen hab ich extra auch von "aktuell" gesprochen, nicht von "Steinzeit". ;-)
Der Rest hat für das gesamte .NET Ökosystem seine Gültigkeit bzw. im Endeffekt für alle Managed Code Runtimes (Java, .NET, Kotlin..)