Laden...

12 MB Große Exe - Datei - Warum?

Erstellt von Sindelfinger vor einem Jahr Letzter Beitrag vor einem Jahr 939 Views
S
Sindelfinger Themenstarter:in
39 Beiträge seit 2019
vor einem Jahr
12 MB Große Exe - Datei - Warum?

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.

2 stupid 4 chess? No way.
2 stupid 4 C#? It seems so X(

2.078 Beiträge seit 2012
vor einem Jahr

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.

S
Sindelfinger Themenstarter:in
39 Beiträge seit 2019
vor einem Jahr

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.

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ß".

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.

2 stupid 4 chess? No way.
2 stupid 4 C#? It seems so X(

2.078 Beiträge seit 2012
vor einem Jahr

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.

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)

16.807 Beiträge seit 2008
vor einem Jahr

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.

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
2.078 Beiträge seit 2012
vor einem Jahr

@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.

16.807 Beiträge seit 2008
vor einem Jahr

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..)

S
Sindelfinger Themenstarter:in
39 Beiträge seit 2019
vor einem Jahr

Hallo Freunde!

Ich habe ja geschrieben, dass es nicht eilt, also bin ich erst jetzt dazu gekommen, mich dieser Kuriosität weiter zu widmen.

Wirf doch mal so lange Inhalte raus, bis Du einen deutlichen Größenunterschied sehen kannst.

Habe ich andersrum gemacht: Ein leeres Projekt erstellt und nach und nach die Inhalte eingefügt. Sehr verwundert hat mich die Tatsache, dass nichts fehlte und die exe dann plötzlich doch nur knappe 500k hatte. Wird wohl ein miraculum bleiben, aber stört ja nicht weiter.

Korrekt. Deswegen hab ich extra auch von "aktuell" gesprochen, nicht von "Steinzeit". 😉

Nicht ganz Steinzeit. Nur eben alte Geräte.

Die maximale Größe eine Exe-Datei unter Windows kann aktuell 4 GB betragen.

Da stand mir dann doch kurz die Klappe offen. Darauf war ich nicht vorbereitet. Ich erinnere mich noch an meine erste Festplatte. Die hatte 10MB, kostete fast 1000 Mark und wog über 1 kg. Da hat man sich früh daran gewöhnt, mit den vorhandenen Ressourcen sparsam umzugehen. Rechne mal hoch, wie schwer die Festplatte mit der damaligen Packungsdichte wäre, wenn dort in 4GB - Programm laufen müsste. Ganz zu schweigen vom Arbeitsspeicher (damals Erweiterung von 4 auf 8 MB schlappe 500 DM).

Für die Jüngeren: DM war die "Deutsche Mark". Damit hat man in der "Steinzeit" bezahlt 😉

Die Self - Contained Geschichte gefällt mir. Eignet sich sehr gut für ältere Geräte im Inselbetrieb.

2 stupid 4 chess? No way.
2 stupid 4 C#? It seems so X(

2.078 Beiträge seit 2012
vor einem Jahr

Sehr verwundert hat mich die Tatsache, dass nichts fehlte und die exe dann plötzlich doch nur knappe 500k hatte

Dann fehlt doch irgendwas, sowas wie ein Mirakulum gibt's nicht 😉
Vergleich doch mal Vorher und Nachher, vielleicht gibt's in der Projekt-Datei doch etwas, was Du übersehen hast und nicht brauchst?
Und in der "modernen Zeit" mit dem SDK-Format reicht bei vielen Dateien auch aus, sie nur ins Projektverzeichnis zu legen, sofern nichts anderes eingestellt, werden die automatisch hinzugefügt.
WinMerge bietet sich für sowas sehr an.

Für die Jüngeren: DM war die "Deutsche Mark". Damit hat man in der "Steinzeit" bezahlt 😉

Naja, wenn .NET 4.8 schon Steinzeit ist, müsstest Du eher im Denarsystem zahlen 😉