Wie sendet man eine in c++ programmierte exe richtig ?
-
Hallo liebe Comunety ich will meine arbeiten versenden und weiß nicht wiso aber immer wenn ich versende dann steht bei dem anwender das er eine bestimmte datei nicht besitzt und das teil geht ned an, wollte fragen muss man da wirklich 10000 dateien mit 1 exe schicken oder gibt es wege einfach nur die exe zu schicken und es läuft dann ?
Bitte um schnelle Antwort !
LG 
-
BigAnonym19955 schrieb:
Hallo liebe Comunety ich will meine arbeiten versenden und weiß nicht wiso aber immer wenn ich versende dann steht bei dem anwender das er eine bestimmte datei nicht besitzt und das teil geht ned an, wollte fragen muss man da wirklich 10000 dateien mit 1 exe schicken oder gibt es wege einfach nur die exe zu schicken und es läuft dann ?
Bitte um schnelle Antwort ! LG Das gehört ins "Rund um die Programmierung" Board.
Ja, du musst alle erforderlichen DLLs und Resourcen mitlieferen. Die DLLs sind Compiler- und Library-abhängig (das heißt, wenn du Libs oder APIs überhaupt benutzt) , und die Resourcen müssen natürlich von dir organisiert sein. Hol dir mal das Tool Dependency Walker und stöber mal im Netz rum nach statischem und dynamischem Linken.P.S.: Du kannst dir auch einen Installer basteln. Dazu gibt es auch massig Info im Netz. Ich würde aber an deiner Stelle lieber eine einfache ZIP-Datei nehmen.
-
-
BigAnonym19955 schrieb:
-
Oder statisch linken (in den Projekt-Linkereinstellungen ändern).
-
Für die korrekte Auslieferung empfiehlt sich ein Installer, der ist benutzerfreundlich und hat zahlreiche Vorteile:
- Die Software lässt sich wieder deinstallieren ohne einfach zu löschen
- Der Benutzer muss nur einmalig diese Aktion als Admin ausführen
- Man kann EULA/AGB mit einbinden
- Startmenü/Schnellstart-Elemente lassen sich automatisch einfügen (bitte aber optional!)
- Viele Installer bieten auch an manche DLLs im Systemverzeichnis statt im Ordner selbst zu führen; die MSVC-Runtime z.B. gehört nicht in den Programmordner, da es sich um eine "shared library" handeltVisual Studio liefert Installer-Projekte mit (ich würde aber das nehmen, wo man nicht noch extra etwas installieren muss, auch wenn man das über Google bei der MSDN als Erstes findet; das ist nur eine Trial, die - soweit ich fand - keine shared libs anbot). So ein Projekt habe ich mir erstellt und bin sehr zufrieden; das reicht für die meisten Installationen meiner Meinung nach aus.
Edit: Statisches Linken der Runtime ist natürlich genau so blödsinnig... Auch QT, wxWidgets oder andere vermutlich von mehrerer Software verwendeten Libraries gehören nicht statisch gelinkt, weil man unnötig Speicherplatz verwendet und sich gegen Updates (z.B. auch durch andere Software) sperrt.
-
Eisflamme schrieb:
Edit: Statisches Linken der Runtime ist natürlich genau so blödsinnig...
Das würde ich so nicht sagen. Zum Teil ist das sehr nützlich, gerade bei Qt würde ich sagen statisch Linken ist besser weil das Speicherplatz spart und das Ausliefern vereinfacht.
-
Eisflamme schrieb:
Statisches Linken der Runtime ist natürlich genau so blödsinnig...
Äh.. nein, ist es nicht. Der TE hat mit an 100% grenzender Wahrscheinlichkeit irgendein Miniprogramm gebaut, für dass er keinen Installer oder sonstigen Schwachsinn braucht. Das bisschen Speicher was dazu kommt, interessiert heutzutage wirklich niemanden mehr, jedenfalls nicht bei einer .exe. Statisch linken ist der einzige ordentliche Tipp, der das Problem des TE unkompliziert und mit 6 Klicks löst.
-
Seh ich auch so. Man sollte imho grundsaetzlich statisch linken, wenn es die Lizenz nicht verbietet (Qt).
Installer sind extrem nervig und meistens auch unnoetig. Zudem muellen sie die Festplatte und die Registry voll und beim deinstallieren wird oft nicht alles entfernt. Der Benutzer hat da kaum Kontrolle, was diese Installer mit seinem System machen. Hinzu kommt, dass Installer mit Administrationsrechten ausgefuehrt werden muessen und nicht jeder Benutzer moechte jedes x-beliebige Programm aus dem Netz mit Administrationsrechten ausfuehren.
Also ich sehe in Installer eher nur Nachteile ...Statisch linken in Microsoft Visual C++ 10 / 2010:
ALT + F7
C++ aufklappen
Codegenerierung waehlen
Eigenschaft Laufzeitbibliothek von "Multithreaded Debug" auf "Multithread" aendern (im Release-Modus).Und dann sollte das Programm ueberall ohne zusaetzliche Runtime laufen.
-
Aehm ich meinte von "Multithreaded DLL" zu "Multithreaded" aendern
-
Ferris schrieb:
Seh ich auch so. Man sollte imho grundsaetzlich statisch linken, wenn es die Lizenz nicht verbietet (Qt).
Ähm, wieso erwähnst du Qt? LGPL?
Damit kannst du seit 4.5 auch ohne komerzielle Lizenz statisch linken, wenn du die object files (und auch, falls du die Source verändert kompiliert hast, die veränderte Qt-Source) mit anbietest (die eh keiner haben will).Aber back to topic.
-
Okay, also das Argument, dass es für TE jetzt gerade einfacher ist, ist natürlich völlig korrekt, daher würde ich jetzt auch zu einem einfachen Archiv mit statischem Linken raten. Drum ist das Folgende auch nicht auf TE speziell ausgerichtet, sondern allgemein.
Falls es in einer Library zu einem Bug kommt, der in einer neueren Version gelöst wird, sperrt man sich dagegen mit statischem Linken (wobei man dagegenhalten kann, dass Updates ja auch ihrerseits Bugs enthalten können, aber der Fall ist IMO unwahrscheinlicher als das gegenteilige Ereignis).
Und wenn man 10 Programme hat und jede 10 Libraries nutzt, hat man die Libraries in 100-facher Kopie. Wenn eine Library im Schnitt 2MB groß ist, hat man schon 180MB nutzlosen Speicher auf der Platte. Das lässt sich ja auch schnell auf 100 Programme hochrechnen, also ich finde das nicht besonders benutzerfreundlich und würde mich da über schlanke EXEs freuen. Ich sehe auch den Nachteil im dynamischen Linken nicht, wenn die DLLs eben im shared-library-Verzeichnis liegen (das erfordert natürlich den Installer, wenn man den für sich als Nachteil sieht; und ja, man muss bei den Librarys natürlich schon abwägen, wie häufig die auf einer Client-Maschine sind, was auch die MB-Summe drücken könnte).
Anderes Problem bei statischem Linken ist bei Updates, dass immer die aufgeblähte exe heruntergeladen werden muss, auch wenn sich wirklich nur am Hauptprogramm etwas geändert hat und nicht etwa an der Runtime. Ich weiß dabei gerade nicht, um wie viel sich die vergrößert, aber wenn sich beim Update die Downloadzeit vergrößert, finde ich das nicht schön, ein paar Sekunden mehr Warten können für den Benutzer nervig sein (auch wenn man das bei größerer Software natürlich eh asynchron gestalten sollte, aber viele mittelgroße Programme lassen den Benutzer eben kurz warten, was ich auch in Ordnung finde).
Zudem muellen sie die Festplatte und die Registry voll und beim deinstallieren wird oft nicht alles entfernt. Der Benutzer hat da kaum Kontrolle, was diese Installer mit seinem System machen. Hinzu kommt, dass Installer mit Administrationsrechten ausgefuehrt werden muessen und nicht jeder Benutzer moechte jedes x-beliebige Programm aus dem Netz mit Administrationsrechten ausfuehren.
Festplatte zumüllen liegt ja im Bereich dessen, was der Installer-Ersteller macht, das ist kein Nachteil am Installer per se. Und "Registry vollmüllen" kann das Programm auch so und dann hat man aber keine Deinstallation und kriegt es daher garantiert nicht mehr raus. Das Argument, dass der mit Adminrechten ausgeführt werden muss, ist auch eine Vertrauenssache, aber kein Nachteil an sich. Die Kopie ins Programmverzeichnis muss ja auch mit Adminrechten geschehen.
Und wenn man eine EULA mitliefern will oder nochmal auf Lizenzen hinweisen möchte, kann man das eben prima im Installer einbauen. Ich fand den bis vor kurzem auch ziemlich störend und habe gesagt, ein einfaches Archiv wäre besser. Der Punkt ist aber, dass viele Benutzer den Installer mögen, weil es "professionell" und "aufgeräumt" wirkt, wenn eine Installationssoftware einem durch den Prozess begleitet und dann auch schon die schönen Icons und Startmenüeinträge erstellt, die er gerne benutzt (oder was für Pendants es da in Windows8 gibt). Der Ottonormalverbraucher will kein Archiv entpacken und im Programmverzeichnis einen Ordner erstellen und es da reinschieben. Keine Frage: Das hängt enorm von der Zielgruppe ab, ich finde es aber gerade für kommerziell vertriebene Software angebrachter einen Installer statt ein Archiv zu verwenden.
-
Sone schrieb:
Ähm, wieso erwähnst du Qt? LGPL?
Damit kannst du seit 4.5 auch ohne komerzielle Lizenz statisch linken,Wenn ich mich jetzt nicht total irre, muss man für Projekte, die nicht quelloffen sein sollen, LGPL-Libs dynamisch linken. Es sei denn, die verwendete Bibliothek macht da noch extra eine Ausnahme, dass man sie statisch linken darf, ohne den restlichen Quellcode rausrücken zu müssen.