Versions- und Debuginformationen aus der Release-Version entfernen
-
Wie bekomme ich bei einem Visual C#-Projekt eigentlich die Versionsinformationen (Dateiversion, Firma, Originaldateiname etc.) aus der Exe raus? Ich hab schon im Projekt die AssemblyInfo.cs gelöscht (Wozu ist die eigentlich gut?), aber das hat nichts gebracht.
Und dann müßte ich noch wissen, wie ich die Debug-Informationen aus der Release-Version rausbekomme. Damit meine ich die Pfadangabe zur PDB-Datei (die ja immer richtig schön mit einem absoluten Pfad angegeben wird) und was es da unter Umständen sonst noch so gibt, das in einer Programmversion für Benutzer eigentlich nichts verloren hat.
-
Versuch mal in den Projekteinstellungen unter Erstellen -> Erweitert bei Ausgabe die Debuginformationen komplett ab zustellen.
-
das in einer Programmversion für Benutzer eigentlich nichts verloren hat
Das ist Ansichtssache. Es stört den Benutzer ja nicht, wieso es also nicht einfach drinlassen?
-
Welche Gründe würden denn die Aussage von NES unterstreichen ?
-
Knuddlbaer schrieb:
Versuch mal in den Projekteinstellungen unter Erstellen -> Erweitert bei Ausgabe die Debuginformationen komplett ab zustellen.
Ich guck mal morgen nach.
Und wie geht das jetzt mit den Versionsinformationen? Bei C++ mit MFC brauchte ich nur dieses eine Teil aus der Ressourcedatei löschen, aber was mache ich in C#? Meine Programme haben weder Versionsnummern, noch gehören sie zu einer Firma oder ähnlichem. Ich wollte diese Versionsregisterkarte bei den Dateieigenschaften nie in meinen Programmen haben. Aber selbst wenn ich nur auf Kommandozeile mit "csc Program.cs" kompiliere, stehen die drin.
hustbaer schrieb:
das in einer Programmversion für Benutzer eigentlich nichts verloren hat
Das ist Ansichtssache. Es stört den Benutzer ja nicht, wieso es also nicht einfach drinlassen?
Weil der String "C:\Dokumente und Einstellungen\<Benutzername>\Eigene Dateien\Meine supercoolen C#-Programme, die alle anderen bloß pwnen\Unvollendete Programme\<Projektname>\<Projektname>\bin\Release\<Projektname>.pdb" eben fehl am Platz ist. Das sind interne Informationen und ich finde, daß eine Exe-Datei, mal abgesehen vom generierten Timestamp, bei jedem Kompiliervorgang desselben Quellcodes unter derselben IDE und mit denselben Compilereinstellungen auch immer gleich aussehen und sich der Inhalt nicht ändern sollte, abhängig davon, wo auf der Festplatte beim Kompilieren zufällig der Projektordner liegt.
-
Die pdb Geschichten solltest Du wie beschrieben raus bekommen sollen. Die Attribute Versionsnummer sind für Dich selbst hilfreich wenn es mal zu Problemen kommt - und Felder wie Unternehmen etc. kannst Du doch einfach leer lassen. Über die Assemlby.cs kannst Du auch noch Einfluss darauf nehmen. Hierzu solltest Du aber mal die MSDN konsultieren.
-
Weil der String "C:\Dokumente und Einstellungen\<Benutzername>\Eigene Dateien\Meine supercoolen C#-Programme, die alle anderen bloß pwnen\Unvollendete Programme\<Projektname>\<Projektname>\bin\Release\<Projektname>.pdb" eben fehl am Platz ist. Das sind interne Informationen und ich finde, daß eine Exe-Datei, mal abgesehen vom generierten Timestamp, bei jedem Kompiliervorgang desselben Quellcodes unter derselben IDE und mit denselben Compilereinstellungen auch immer gleich aussehen und sich der Inhalt nicht ändern sollte, abhängig davon, wo auf der Festplatte beim Kompilieren zufällig der Projektordner liegt.
Hm. Wenn du meinst
Ich werde vermutlich deine Meinung nicht ändern können (was ja auch ganz OK ist), aber ich sehe das Problem einfach nicht. Steht halt der Pfad drinnen. Ist der Geheim?
Du kannst das Projekt ja unter C:\blubb\xyz\blah.csproj ablegen und dort compilieren, das sagt dann genau niemandem was.Ich habe irgendwie den Eindruck der Wunsch diesen Pfad zu entfernen entsteht nur aus der Einstellung "das geht keinen was an". Die ich dann etwas kindisch fände.
Ist doch egal was wen etwas angeht oder nicht, wichtig ist letzlich doch nur was es ausmacht/schadet wenn es jemand weiss. Und beim Pfad unter dem etwas compiliert wurde ist es einfach so dass es meist vollkommen egal ist.Falls ich mich irre würde mich auch interessieren welche Gründe du sonst hast das entfernen zu wollen. Falls du denkst es wirkt unproffessionell kann ich dich beruhigen: PDB Pfade hab' ich schon in vielen sehr proffessionellen Programmen gefunden.
BTW: wenn dich sowas stört, dann guck dir mal genau an was in Emails die du irgendwem schickst so alles drinsteht (vorausgesetzt du verwendest ein lokales Email-Programm). Also in den Headern. Könnte sein dass dich das auch stört
Und nochwas zu dem Thema: wenn du DLLs compilierst, guck dir mal an was man da alleine alles aus den Export-Namen rauslesen kann. Bzw. bei .NET sowieso die ganzen Metadaten die auch in EXEn vorhanden sind. Alle deine Klassennamen/Funktionsnamen, Felddefinitionen etc. - alles hübsch 1:1 auslesbar. Wieder etwas wo ich der Meinung bin es ist egal, aber vermute dass es dich u.U. stören könnte.
Ich wollte diese Versionsregisterkarte bei den Dateieigenschaften nie in meinen Programmen haben. Aber selbst wenn ich nur auf Kommandozeile mit "csc Program.cs" kompiliere, stehen die drin.
Vermutlich kannst du die mit einem Resource-Editor einfach entfernen. Wobei ich auch nicht verstehe wieso dich das stört. Schreibst du einfach überall "blah" rein, und als Version 0.0.0.0
Aber egal, wie gesagt, mit nem Resource-Editor sollte das gehen. Einfach mal suchen, da gibt's sicher auch scriptbare, so dass du das als Post-Build-Step reinhängen kannst. Also falls es anders nicht geht. (Bei C++ Projekten geht es
-
Die Versionsinformationen wirst du unter keinen Umständen entfernen können, da Versionierung ein wichtiges Konzept von .Net ist. Überall und ständig wird auf die Version von Assemblies geschaut, seis nun das einfache Laden von Assemblies, Serialisierung oder sowas. Durch die Versionierung entsteht ja grad erst eine Stärke von .Net dass gleichnamige Assemblies in verschiedenen Versionen coexistieren können. Dadurch vesucht man ja der "Dll-Hell" Herr zu werden.
-
@Talla:
Was du schreibst stimmt AFAIK nur wenn man "strong named" Assemblies verwendet. Was man kann, aber nicht muss.
-
hustbaer schrieb:
Ich werde vermutlich deine Meinung nicht ändern können (was ja auch ganz OK ist), aber ich sehe das Problem einfach nicht. Steht halt der Pfad drinnen. Ist der Geheim?
Nein, das hat nichts mit geheim zu tun. Ich finde nur, es sieht einfach räudig aus, wenn im Programm irgendwelche temporären Dinge des Programmierers drinstehen, die nichtmal einen Zweck erfüllen, da ich dem Benutzer ja wohl kaum die PDB-Datei mitliefere. Und wenn doch, dann müßte er sie erstmal an eine Stelle legen, die meiner lokalen Ordnerstruktur entspricht.
Wie gesagt, mit geheimhalten hat das nichts zu tun. Ich bin nur für Ordnung. Und deshalb hat der lokale Kompilierungspfad in der fertigen Exe nichts zu suchen. Wenn ich einen Brief schreibe, notier ich ja unten in der Ecke auch nicht: "Am Schreibtisch entstanden, links neben der Keksdose."hustbaer schrieb:
Vermutlich kannst du die mit einem Resource-Editor einfach entfernen. Wobei ich auch nicht verstehe wieso dich das stört. Schreibst du einfach überall "blah" rein, und als Version 0.0.0.0
Auch hier: Räudig. Wenn ich keine Versionierung habe, soll der Mist raus.
Kurz gesagt: Ich hasse einfach irgendwelchen Datenmüll. Bei irgendeiner ollen E-Mail, die man einmal verschickt, mag das noch gehen. Aber Programme, die ich schreibe, zum Beispiel irgendwelche kleinen Spiele oder so etwas, und die sich dann auch andere ansehen, die sollen eben nicht unnützen Datenmüll enthalten.
hustbaer schrieb:
Aber egal, wie gesagt, mit nem Resource-Editor sollte das gehen. Einfach mal suchen, da gibt's sicher auch scriptbare, so dass du das als Post-Build-Step reinhängen kannst. Also falls es anders nicht geht. (Bei C++ Projekten geht es
Das heißt, ich habe höchstwahrscheinlich keine Möglichkeit, das ganze von Visual Studio aus gleich beim Kompilieren abzuschalten, sondern muß mich danach mit einem Drittanbieterprogramm in die Exe hacken?
-
[edit]macht ja doch keinen Sinn[/edit]
Wird bei einem Binären Serialisieren nicht die Versionsnummer verwurstet ? Beim anlegen einer Referenz kann die Versionsnummer auch eine wichtige Rolle spielen. (Ohne das sie Signiert ist.)
