Ich habe eine C ++ - Anwendung, die ursprünglich mit Visual Studio 6.0 geschrieben wurde
Die Anwendung ist standardmäßige und rohe Win32-API, kein MFC (* Edit 2), keine .NET-Datei, statisch verknüpfte ausführbare Datei mit mehreren Threads.
Ich habe bis heute (2010) alle Versionen von Visual Studio migriert und hatte bis jetzt keine Probleme:
Er kompiliert und läuft perfekt mit VS2010 ABER die generierte ausführbare Datei ist vier (4) mal größer!
Ich habe alle Möglichkeiten ausprobiert, die ich kenne (Optimierungen, Debug-Informationen entfernen , etc ..), ohne Ergebnisse. Zugegeben, ich bin neu in VS2010, aber nicht in Visual Studio.
Ist jemand auf dieses Problem gestoßen? Nochmal: Ich benutze keine Frameworks, es ist eine rohe, statisch verknüpfte Win32-Anwendung, keine DLLs, kein ODBC, kein Netzwerk, kein .NET.
Ich hoffe, dass meine ausführbaren Dateien noch einmal klein sind. Ich danke Ihnen für die Eingabe.
Bearbeiten 1: Originalgröße = 626 KB (VS6.0, VS2008) Aufgeblähte Größe = 2.013KB (VS2010)
Bearbeiten 2: Nach einigen Recherchen und Dumps entdeckte ich einen versteckten Verweis auf MFC. Ursprünglich habe ich gesagt, dass es MFC nicht verwendet, aber es tut.
Die Größenzunahme kann durch Änderungen am MFC verursacht werden. Hier ist eine Erklärung, und hier ist eine Problemumgehung des gleichen Autors, die die Größe der ausführbaren Datei in Regionen zurückbringt, in denen es 2008 war. Die Problemumgehung umfasst das Bearbeiten von Kopien von MFC-Quelldateien, obwohl nicht jeder glücklich sein kann mit, und das muss nach jedem Update wiederholt werden, z nach der Installation eines Visual Studio Service Packs.
Aktualisierung:
Es sieht so aus, als ob das OP keine MFC verwendet, also könnten dies zwei verschiedene Probleme sein. Ich habe die Größenzunahme selbst erlebt, kann aber leider nicht sagen, ob durch MFC verursacht oder nicht, da mein Projekt statisch auf den MFC verweist.
Wenn Sie eine statische Verknüpfung verwenden, schlage ich vor, die Linker-Schalter zu verwenden, wenn Sie in der Befehlszeile mit der folgenden Syntax kompilieren:
cl / Ox [Ihre C ++ Quelldatei (en)] [erforderliche Bibliotheken falls vorhanden] [erforderliche Ressourcendateien] / link / FILEALIGN: 512 / OPT: REF / OPT: ICF / INKREMENTAL: NEIN
Wenn Sie innerhalb der Visual Studio-IDE erstellen, überprüfen Sie die Linkereinstellungen, indem Sie die Projekteigenschaften im Menü auswählen. Wählen Sie in der Konfiguration das Release und klicken Sie dann auf die Linkereinstellungen im linken Bereich. Dadurch wird Ihnen eine Liste der Konfigurationen angezeigt, die den standardmäßig eingestellten Linkereinstellungen entsprechen.
Geben Sie in der Befehlszeile unter dem Linker die Option / FILEALIGN: 512 im Bereich Additional options ein und klicken Sie auf Apply. Deaktivieren Sie in der allgemeinen Option unter dem Linker die inkrementelle Verknüpfung, indem Sie Nein (/ INCREMENTAL: NO) auswählen. Wählen Sie in der Debugging-Option des Linkers Nein für Generate Debug Info. Für die Linker-Optimierung wählen Sie die Option Nicht referenzierte Daten entfernen (/ OPT: REF) in den Referenzen und entfernen redundante COMDATs (/ OPT: ICF) in der COMDAT-Faltung aktivieren.
Stellen Sie bei der Compiler-Optimierung sicher, dass die Release-Konfiguration ausgewählt ist. Klicken Sie im linken Bereich auf die C / C ++ - Strukturansicht, und klicken Sie dann auf Optimierung, vollständige Optimierung auswählen (/ Ox). Wählen Sie in der allgemeinen Einstellung unter C / C ++ für das Debug Information Format Disabled aus.
Vergessen Sie nicht, für jede Änderung, die Sie vornehmen, auf die Schaltfläche Übernehmen zu klicken.
Ich hoffe, dass alles, was ich hier erwähnt habe, hilfreich für Sie sein würde und all dies gilt für Visual C ++ 2005 und 2008, aber hoffentlich würde es auch für Visual C ++ 2010 gelten, wenn nicht, lesen Sie bitte die Dokumentation zu Ihrem Visual C ++ 2010 Installation.
Haben Sie das Standard-Plattformziel bei "Any CPU" verlassen? Wenn dies der Fall ist, ändern Sie es für nur 32-Bit-Code in x86. Ich schätze, das wird den größten Unterschied ausmachen. Der Rest ist wahrscheinlich in Änderungen der Compiler-Optimierung (aggressiveres Loop-Enrolling und was nicht dort gehandhabt wurde, wo die Größe für die Geschwindigkeit gehandelt wurde, da RAM billig ist). Ich glaube, dass alle granularen Optimierungen noch über die Befehlszeile verfügbar sind, aber viele wurden in den UI-Optionen ausgeblendet.
Siehe Gibt es irgendwelche Werkzeuge zum Aufspüren von Bloat in C ++? - einige Techniken, die analysieren, was zur ausführbaren Dateigröße beiträgt, werden dort beschrieben. Sobald Sie die Analyse sowohl für VC 6 als auch für VS 2010 durchgeführt haben, werden Sie hoffentlich etwas Nützliches finden.
Es gibt ein bestimmtes Problem, das mich bei der Portierung von VC 6 auf eine Visual Studio-Edition getroffen hat: Einige Optimierungsoptionen haben sich geändert, und die Werte, die ich im VC 6-Projekt verwendete, wurden nicht mehr unterstützt Die von VS produzierte exe wurde überhaupt nicht optimiert, was sowohl zu einem ausführbaren Bloat als auch zu einer langsamen Performance führte. Überprüfen Sie Ihre Optimierungseinstellungen in Eigenschaften / C / C ++ / Optimierung und stellen Sie sicher, dass die Optimierung eingeschaltet ist / Ox, / O2 oder / O1.
Dies liegt daran, dass Microsoft in VS2010 Funktionen hinzugefügt hat, die HTML-Komponenten in einem Dialogfenster erlauben, so dass eine Menge Dinge hineingezogen und verlinkt werden, selbst wenn Sie sie nicht verwenden und die Optimierungen und Optionen und das Entfernen von nicht referenziertem Code nicht helfen. Es gibt keinen "guten" Weg, den Code zu entfernen, aber es gibt einige gehackte Wege. Wir kompilieren unsere größenkritischen Sachen auf VS2008 trotzdem deswegen. Randnotiz, unser Nicht-GUI-Code kompiliert tatsächlich kleiner für das, was es wert ist. Hoffe, dass MS eine Option dafür in einer Reparatur / einem Patch hat, damit ich alles auf VS2010 machen kann, aber ich halte nicht die Luft an ...
Tags und Links size visual-studio-2010 executable