Größe von *.exe

[Wichtelherbert]

Hallo zusammen,

kann mir evtl. jemand die kompilierten Größen verraten mit welchen man bei einem Programm nach Kompilierung rechnen kann?
Hätte jetzt an einer normale GUI gedacht, mit zwei Textfeldern und einem Button.

Im folgenden geht es um eine C# Anwendung mit WPF und Net Core 3.1. und eine C++ Anwendung mit QT erstellt.
Am Ende sollten beide Daten auf jedem Windows Rechner immer ausführbar sein, oder zusätzliche Dateien mitzugeben.

Gibt doch bestimmt jemand der in etwa Aussagen dazu treffen kann.

Vielen Dank

 

[Bagbag]

Eine kleine, einfache C# Anwendung ohne weitere Libraries ist im <50kb Bereich. Die ganze Runtime ist ja schon auf dem Rechner.

Bei Qt ist es ganz ähnlich, außer du machst eine static linked binary (glaube ich).

 

[KitKat::new()]

Bei Qt ist es ganz ähnlich,

Bei QT muss man dlls mitliefern - Static linking könnte sogar Geld kosten

 

[Wichtelherbert]

Danke Euch beiden.
Hatte gestern die Problematik das ich ein einfache Net Core *.exe weitergeben wollte und diese sich nicht öffnen ließ das die entsprechende Library nicht dabei war.
Gerade wenn man Core 3.1 oder höher nutzt, dann ist dies ja bei den meisten noch nicht mit installiert also muss diese mitgegeben werden, was die Datei auf über 120 MB aufbläst.

Wäre das bei QT auch der Fall, wenn davon ausgeht das man mit einer bezahlten Lizenz statisch linkt.

 

[gymfan]

.NET Core Runtine und Qt Runtime sollen unter Windows standardmäßig installiert sein? Wird das bei Win 11 mittlerweile mitgeliefert?

Wenn ich das hier sehe, dann ist es das erwartungsgemäß nicht.
https://github.com/dotnet/core/issues/4600

Man kann wohl eine Art "statisches Linking" betreiben ("Our recommendation here is to create self-contained applications"), landet dann aber halt (laut den Aussagen dort) locker bei 70++ MB für ein simpeles "hello world".

Die Frage für mich ist halt. warum .NET Core, wenn man als Target nur Windows hat.

Wenn ich mir AVIDemux (Qt) ansehe, dann scheinen die Qt-DLLs dort 20-30 MB groß zu sein. Was die von Qt nutzen weiss ich natürlich nicht. Bei XNViewMP sind es dann schon mind. 50 MB für DLLs, die eindeutig mit QT5 zu tun haben.

 

[Dalek]

Das hängt extrem stark von der Programmierumgebung ab und wieviel Runtime Environment und Libraries man da mitliefern muss.

.NET benötigt eine recht große Laufzeitumgebung, das muss den JIT und ne ganze Menge Libraries mitliefern. Und seit .NET Core ist es nicht mehr üblich das diese Umgebung vorinstalliert wird, jede Anwendung sollte die selbst mitbringen. Man kann das Framework mit reinkompilieren, aber dann ist man mindestens im höheren zweistelligem MB Bereich. Das wird in Zukunft besser mit mehr Trimming, aber das dauert noch bzw. ist momentan nur was für Leute die sich da im Detail etwas auskennen.

Die Frage für mich ist halt. warum .NET Core, wenn man als Target nur Windows hat.

.NET Core bzw. .NET5 ist die moderne Version von .NET. Das alte .NET Framework sollte man wirklich nicht mehr für neue Anwendungen verwenden außer man braucht bestimmte Sachen die es in .NET Core nicht mehr gibt. Auch wenn man nur auf Windows geht ist .NET Core in vielen Aspekten deutlich besser und schneller als .NET Framework.

 

[Bagbag]

Bei QT muss man dlls mitliefern

Gab es da nicht auch shared libraries (unter Windows), die man global installieren kann? Aber klar, wenn die jemand nicht hat, müssen sie natürlich auch erstmal installiert werden. Aber das Programm selbst kann klein bleiben.

.NET Core Runtine und Qt Runtime sollen unter Windows standardmäßig installiert sein?

Nein, aber das ist eben wie bei den ganzen VC++ Runtimes, die werden einmal installiert und können dann von allen Programmen benutzt werden. Ob man das jetzt zur Programmgröße dazuzählen will oder nicht ist wohl Geschmackssache.


Wenn du InnoSetup zum verteilen deiner Software nutzt, musst du auch nicht immer die Runtime mitliefern. Die wird dann nur heruntergeladen, wenn sie nicht vorhanden ist: https://github.com/DomGries/InnoDependencyInstaller
Gibts bestimmt andere Lösungen dafür. Zeigt dotnet core nicht nicht sogar eine Meldung beim Start an, wenn die Runtime fehlt? Beim .NET Framework war es jedenfalls so und mann konnte es direkt da dann automatisch installieren lassen.

 

[gymfan]

.NET Core bzw. .NET5 ist die moderne Version von .NET. Das alte .NET Framework sollte man wirklich nicht mehr für neue Anwendungen verwenden außer man braucht bestimmte Sachen die es in .NET Core nicht mehr gibt. Auch wenn man nur auf Windows geht ist .NET Core in vielen Aspekten deutlich besser und schneller als .NET Framework.

Mir ist durchaus klar, was .NET Core und .NET 5 ist und wo ich das bei uns in der Firma überall nicht finde und auch nicht installieren kann/darf/will. Je nach Client, auf dem die Sachen eingesetzt werden müssen, kann noch nicht einmal .NET 4.8 genutzt werden.

Nein, aber das ist eben wie bei den ganzen VC++ Runtimes, die werden einmal installiert und können dann von allen Programmen benutzt werden. Ob man das jetzt zur Programmgröße dazuzählen will oder nicht ist wohl Geschmackssache.

Der TO wollte es, weil es ihm u.U. ähnlich geht wie mir seit Jahrzehnten in der Firma: ich kann/darf dort, wo ich meine Tools ausführe, nicht mal eben irgendwas installieren. Entweder ich weiss, dass die Grundlagen dort gegeben sind, ich muss einen Weg finden, alles (und zwar ohne Installation) mitzuliefern oder das Programm wird nicht laufen.

Aber klar, wenn ich heute ein grüßeres SW-Projekt beginne, wird sowas halt an Voraussetzung definiert. Das ist dann aber kein Tool das nur ein paar Textboxen und Buttons hat.

 

[Bagbag]

ich kann/darf dort, wo ich meine Tools ausführe, nicht mal eben irgendwas installieren

Das habe ich im ersten Post irgendwie überlesen oder zu schnell wieder vergessen. Ja, in dem Fall ist das was ich nannte natürlich keine Option.

 

[Wichtelherbert]

...installieren kann/darf/will. Je nach Client, auf dem die Sachen eingesetzt werden müssen, kann noch nicht einmal .NET 4.8 genutzt werden...

Genau so ein Problem habe ich teilweise auch, daher hat mich interessiert wie groß die Anwendung mit C++ und QT wird. Damit sollte (wenn ich für statisch linken bezahle) doch kleinere ausführbare *.exe rauskommen, oder werden die auch riesig?

Sehe es nur bei einem Freund, welcher in Delphi programmiert und da sind einfach Programme max 4 MB groß. Mit ähnlichen Funktionen war mein Versuch mit Net 3.0 gleich 120 MB groß

 

[Dalek]

Genau so ein Problem habe ich teilweise auch, daher hat mich interessiert wie groß die Anwendung mit C++ und QT wird. Damit sollte (wenn ich für statisch linken bezahle) doch kleinere ausführbare *.exe rauskommen, oder werden die auch riesig?

Sehe es nur bei einem Freund, welcher in Delphi programmiert und da sind einfach Programme max 4 MB groß. Mit ähnlichen Funktionen war mein Versuch mit Net 3.0 gleich 120 MB groß

Hier ist ein Blog vom Microsoft zum Thema Trimming in .NET:

https://devblogs.microsoft.com/dotnet/app-trimming-in-net-5/

Du kannst mal ausprobieren ob das bei dir funktioniert und wieviel das bringt. Die richtig aggressiven Trimming Optionen sind leider noch nicht drin bzw. nicht alle Libraries sind darauf vorbereitet und dann entfernen die aggressiven Optionen evtl. Sachen die doch irgendwo benötigt werden.

.NET ist nicht die erste Wahl wenn die Größe der Binaries eine wichtige Rolle spielt. Aber in den meisten Situationen sind größere Binaries absolut akzeptabel. Du kannst aber davon ausgehen das das im .NET Bereich noch deutlich besser wird in Zukuft, durch Blazor hat Microsoft recht viel Ansporn in dieser Richtung Sachen zu verbessern. Wenn man die Anwendung für den Browser kompiliert dann ist die Größe der Binaries sehr wichtig.

 

[Wichtelherbert]

Gibt es vielleicht noch wen der mit C++ und QT sagen kann, ob es große Dateien werden?

 

[andy_m4]

.NET ist nicht die erste Wahl wenn die Größe der Binaries eine wichtige Rolle spielt. Aber in den meisten Situationen sind größere Binaries absolut akzeptabel. Du kannst aber davon ausgehen das das im .NET Bereich noch deutlich besser wird in Zukuft, durch Blazor hat Microsoft recht viel Ansporn in dieser Richtung Sachen zu verbessern.

Bevor das Lob für Microsoft hier zu überschwenglich wird:
Eigentlich ist der Ist-Zustand eher ein Armutszeugnis. Ich kann mich noch an den Turbo Pascal (oder analog dazu diverse C-Compiler) erinnern, deren Compiler/Linker schon passgenaue Executables kompilieren konnte in der nur die Funktionen drin waren, die tatsächlich gebraucht wurden. Gut. Man kann Turbo Pascal jetzt vielleicht nicht direkt mit .NET vergleichen. Aber trotzdem: deutlich über 30 Jahre später eine schon damalige Selbstverständlichkeit als Feature anzupreisen geht mir dann doch ein bisschen weit.
Das ist ungefähr so, als würde ein Autohersteller anpreisen das seine Fabrikate serienmäßig mit ABS ausgestattet sind. :-)

 

[Dalek]

Eigentlich ist der Ist-Zustand eher ein Armutszeugnis. Ich kann mich noch an den Turbo Pascal (oder analog dazu diverse C-Compiler) erinnern, deren Compiler/Linker schon passgenaue Executables kompilieren konnte in der nur die Funktionen drin waren, die tatsächlich gebraucht wurden.

Das ist halt viel schwieriger bzw. unmöglich wenn man Reflection benutzt, und das wird halt in .NET noch viel verwendet. Binary size ist halt auch einfach nicht mehr so wichtig wie vor 30 Jahren, im Verhältnis zur Festplattengröße sind selbst .NET Binaries immer noch viel kleiner als die Pascal Binaries damals ;-).

Es gibt immer genug zu verbessern, und da ist es nicht verwunderlich das ein eher unwichtiges Kriterium vernachlässigt wird. Jetzt mit Blazor wird es wieder wichtiger, und deshalb sind die halt recht spät dran mit den Verbesserungen hier.

 

[andy_m4]

Das ist halt viel schwieriger bzw. unmöglich wenn man Reflection benutzt

Ja. Wie gesagt. Ist nicht unbedingt vergleichbar.

Binary size ist halt auch einfach nicht mehr so wichtig wie vor 30 Jahren, im Verhältnis zur Festplattengröße sind selbst .NET Binaries immer noch viel kleiner als die Pascal Binaries damals ;-).

Ich hab alles in der RAM-Disk. Und nur ein 32-Bit-System. So. Und jetzt kommst Du :-)