Announcement: there is an English version of this forum on Hi, ich habe mal eine Frage zu dem Orginaldateinamen bei Apps die mit Visual Studio 2022 erstellt werden. Wenn ich eine Programm erstelle, z.B. Hallo Welt oder so und hinterher nicht mehrere Dateien haben will sondern eine einzelne exe Datei, kann ich das ja mit der Veröffentlichen Funktion machen. Also Bereitstellungsmodus Frameworkabhängig, Zielruntime win-x64 und Einzelne Datei erstellen. Das alles klappt auch soweit nur steht dann bei der exe die rauskommt beim Orginaldateinamen unter Details nicht Hallo Welt.exe sondern Hallo Welt.dll. Ich finde das etwas unschön und hätte in dem Feld gerne den Namen mit der Endung .exe stehen, wie bekomme ich das hin?
Zuerst den Nicknamen von Programmierer auf DAU ändern. Ansonsten ist das eine Beleidigung.
Programmierer schrieb: > Das alles klappt auch soweit nur steht dann bei der exe die rauskommt > beim Orginaldateinamen unter Details nicht Hallo Welt.exe sondern Hallo > Welt.dll. Das bedeutet, daß Deine Projekteinstellungen keine ausführbare Datei erzeugen, sondern eben eine DLL. Projekt neu anlegen, und diesmal richtig durch den Wizard durchklicken.
DerEgon schrieb: > Programmierer schrieb: >> Das alles klappt auch soweit nur steht dann bei der exe die rauskommt >> beim Orginaldateinamen unter Details nicht Hallo Welt.exe sondern Hallo >> Welt.dll. > > Das bedeutet, daß Deine Projekteinstellungen keine ausführbare Datei > erzeugen, sondern eben eine DLL. > > Projekt neu anlegen, und diesmal richtig durch den Wizard durchklicken. Also dann nochmal in langsam: Es wird beim normalen Kompilierungsvorgang eine EXE erstellt, nein es wurde nicht fehlerhafterweise eine DLL erstellt. Visual Studio 2022 geht aber trotzdem anscheinend jetzt immer hin und verlagert die eigentliche Funktionalität in eine DLL die von dieser Exe aufgerufen wird. Da ich es aber für kleine Tools unpassend finde den ganzen Raffel zu verschicken, will ich alles in die Exe packen, unter anderem dafür gibts die Möglichkeit beim Veröffentlichen alles in eine Exe zu packen, was auch problemlos funktioniert und wie erwartet läuft. Nur ist in den Details der Exe eben der Originalname mit Endung DLL. Ansonsten wäre es schön wenn nur Leute antworten würden die zumindest halbwegs eine Ahnung haben und nicht nur heiße Luft von sich geben.
Angehängte Dateien:
-
1_-_Ausgabetyp.png
15 KB -
2_-_Kompiliert.png
12 KB -
3_-_Details.png
16 KB -
4_-_Profileinstellungen.png
6,5 KB -
5_-_Ergebnis.png
2,8 KB -
6_-_Ergebnis_Details.png
16 KB
Da es offensichtlich bei manchen mit dem Textverständnis und/oder Wissen hapert, hier nochmal als Bilderbuch: 1 - Der Ausgabetyp: Konsolenanwendung, nix Klassenbibliothek. 2 - Was beim Kompilieren rauskommt, 1 EXE, 1 DLL, 1 PDB und 2 JSON. 3 - Und schon an diesem Punkt steht in der EXE als Originaldateiname Hallo Welt.DLL 4 - Wenn ich jetzt das Ganze veröffentliche als einzelne EXE 5 - Die einzelne EXE in die die DLL integriert wurde, jetzt 150 kB. 6 - Die Details der einzelnen EXE, wieder Originalname Hallo Welt.DLL
Kenne mich mit dem .net nicht wirklich aus. Eventuell eine definierte Zielplattform/ runtimr festlegen; sonst wird u.U. ein Universal Binary gebacken (als DLL) und das via einem Stup (exe) gestartet.
Du hast einen Denk-Fehler. Wenn du eine Exe eingestellt hast, wird auch NUR eine EXE erstellt, ALS PROGRAMM. Hier HELLO-WORLD.EXE. Der Rest des Geraffel dort ist das gemiste was der "Hobby-Installer" braucht. Wenn du keine "Zubehör-Dateien" (wie Datenbanken etc.) brauchst kannst du die EXE aus den RELASE-Ordner nehmen und i.d.R. weiter versenden, verteilen etc. Kannst du gern testen. Datei (die Exe) auf ein Stick kopieren und an anderen Rechner (VM) starten. Ist das Framework drauf, läuft die Software einwandfrei. Bei EXTERNEN DLL müssen die natürlich im Paket sein, und auch registriert. Genau so wie Datenbanken die die Exe haben will. Aber das ist dann schon installieren für Fortgeschrittene. ;) Wo bei , genau DAFÜR ist das Geraffel gut. Ansonsten steht da nix gescheites drin. Für den Installations-Creator sind da halt die Infos drin, das er NIX zusätzlichen kopieren muss. Aber VORSICHT, das Spielzeug vergisst gerne was, das muss man ihm dann extra sagen. Datenbanken z.b. MS geht inzwischen davon aus das die Framework o. Runtime-Dateien sich auf Zielrechner befinden. Das da, ist nix anderes als eine Hilfe für ein Installer der billigsten Sorte, bzw. Anweisungen für ihn. So was ähnliches gab es schon bei VB 3.1. ;) Da war das Endergebnis eine SETUP.EXE und ein paar Hilfs-Dateien. Ich weiß zwar nicht wo unter VS es aktuell ist, aber irgendwo gibt es eine Funktion für die Erstellung eines Installers. Der will das ganze Geraffel haben, und macht dann die Installations-Datei. Ich persönlich habe mir den KOSTENPLFICHTIGEN Advance-Installer besorgt. Den würde ich in deinen Beispiel nur sagen wo die "Hello-Word.exe" ist, und den Rest macht er selbst. Der macht eine RICHTIGE Installationsdatei. Mit jede Menge Optionen wie z.b. Backup der alten Dateien, Dateimanagment (Sehr wichtig bei Datenbanken die die Software NICHT selbst anlegt) u.w.mehr.
Schlaumaier schrieb: > Du hast einen Denk-Fehler. Womit du dich eigentlich auskennen müsstest, aber nichtmal das funktioniert bei dir vernünftig. > Wenn du eine Exe eingestellt hast, wird auch NUR eine EXE erstellt, ALS > PROGRAMM. Hier HELLO-WORLD.EXE. Unsinn, seit einiger Zeit kompiliert Visual Studio nur noch in dlls und die exe ist lediglich der Wrapper dafür. > Der Rest des Geraffel dort ist das gemiste was der "Hobby-Installer" > braucht. Unsinn, es gibt da keinen Installer. > Wenn du keine "Zubehör-Dateien" (wie Datenbanken etc.) brauchst kannst > du die EXE aus den RELASE-Ordner nehmen und i.d.R. weiter versenden, > verteilen etc. Kannst du gern testen. Datei (die Exe) auf ein Stick > kopieren und an anderen Rechner (VM) starten. Ist das Framework drauf, > läuft die Software einwandfrei. Da die exe der Wrapper für die dll ist, geht das natürlich nicht. Was du meinst ist die Abhängigkeit vom .net Framework, den man Bereitstellungsmodus (Bild 4 des TO) regeln kann, hat aber mit der Wrapper Nummer so garnix zu tun. > Bei EXTERNEN DLL müssen die natürlich im Paket sein, und auch > registriert. Genau so wie Datenbanken die die Exe haben will. Aber das > ist dann schon installieren für Fortgeschrittene. ;) Wo bei , genau > DAFÜR ist das Geraffel gut. Ansonsten steht da nix gescheites drin. Für > den Installations-Creator sind da halt die Infos drin, das er NIX > zusätzlichen kopieren muss. Aber VORSICHT, das Spielzeug vergisst gerne > was, das muss man ihm dann extra sagen. Datenbanken z.b. ES GIBT DA KEINEN INSTALLER, RAFF ES DOCH! > MS geht inzwischen davon aus das die Framework o. Runtime-Dateien sich > auf Zielrechner befinden. Und wenn man den Bereitstellungsmodus auf Unabhängig stellt, muss das Framework nicht auf dem Zielrechner sein, es wird dann eben nur groß. > Das da, ist nix anderes als eine Hilfe für ein Installer der billigsten > Sorte, bzw. Anweisungen für ihn. Unsinn, das ist kein Installer, immer noch nicht. > So was ähnliches gab es schon bei VB 3.1. ;) Da war das Endergebnis eine > SETUP.EXE und ein paar Hilfs-Dateien. Wieder am Thema vorbei. > Ich weiß zwar nicht wo unter VS es aktuell ist, aber irgendwo gibt es > eine Funktion für die Erstellung eines Installers. Der will das ganze > Geraffel haben, und macht dann die Installations-Datei. Und schon wieder der Installer um den es nicht geht. > Ich persönlich habe mir den KOSTENPLFICHTIGEN Advance-Installer besorgt. Dumm genug bist du dafür, ja. > Den würde ich in deinen Beispiel nur sagen wo die "Hello-Word.exe" ist, > und den Rest macht er selbst. Du hast keine Ahnung. > Der macht eine RICHTIGE Installationsdatei. Mit jede Menge Optionen wie > z.b. Backup der alten Dateien, Dateimanagment (Sehr wichtig bei > Datenbanken die die Software NICHT selbst anlegt) u.w.mehr. Und wieder am Thema Vorbei. Übst du das eigentlich oder kannst du einfach so komplett daneben liegen?
potentielle Handlungsmöglichkeiten: - .rc File anschauen - .manifest anschauen - CMake nutzen - Abhängigkeiten in der Projektmappe ausmisten - sich mal die Ausgabe-Variablen in den Projekteinstellungen anschauen - das feine Manual lesen auf MSDN - ...
Schlaumaier schrieb: > Du hast einen Denk-Fehler Und du mal wieder eine Leseschwäche. Der TO hat nämlich eine ganz andere Frage gehabt.
Tim T. schrieb: > Unsinn, es gibt da keinen Installer. https://docs.microsoft.com/de-de/visualstudio/deployment/installer-projects-net-core?view=vs-2022 Nur für den Fall das du den mal brauchst. Tim T. schrieb: > Unsinn, das ist kein Installer, immer noch nicht. Doch er ist da. ;) MS schwindelt nicht immer. ;) Tim T. schrieb: > Und wieder am Thema Vorbei. Mag ja sein, aber von dir ist auch keine Sinnvolle Antwort.
Programmierer schrieb: > Der Ausgabetyp: Konsolenanwendung, nix Klassenbibliothek. In .NET wird alles über Klassen gemacht auch eine simple Konsolenanwendung. Programmierer schrieb: > 2 - Was beim Kompilieren rauskommt, 1 EXE, 1 DLL, 1 PDB und 2 JSON. Ja das ist bei .NET-Gedöns so. Das eigentliche Programm ist in diesen DLL's drin. Die EXE ist nur ein Vehikel um die DLL('s) am Ende ausführen. Am Ende mußt Du noch viel mehr mit Deinem Programm ausliefern als Du denkst. Wenn Du in Deinem "Hallo Welt" auch nur eine einzige Klasse aus .NET6.0 verwendest, mußt Du als Programmentwickler dafür sorgen das auf dem Zielsystem das .NET6.0 Framework installiert ist bzw. während der Installation mit installiert wird, damit Dein Programm dann auch auf dem Zielsystem ausführbar ist. Wenn Du wirklich nur eine reine (native) EXE witergeben willst, dann mußt Du Dir eine andere Programmiersprache/-umgebung suchen, die aus Deinem Quelltext eine native EXE erzeugt. PittyJ schrieb: > Zuerst den Nicknamen von Programmierer auf DAU ändern. Ansonsten ist das > eine Beleidigung. Die Formulierung von dem Pitty ist zwar nicht sehr nett, aber er hat nicht ganz unrecht, denn Du mußt noch viel lernen und von einem richtigen Programmierer bist Du noch weit entfernt.
Schlaumaier schrieb: > Wenn du eine Exe eingestellt hast, wird auch NUR eine EXE erstellt, ALS > PROGRAMM. Hier HELLO-WORLD.EXE. Du hast eben wieder mal so gar keine Ahnung. Bei .NET wird alles in DLL's verpackt die EXE ist nur ein Hilfsmittel um den Kram am Ende als App erscheinen zu lassen. Dein Folgeposter, der Tim, hat das korrekt erkannt, wenn er schreibt: Tim T. schrieb: > Unsinn, seit einiger Zeit kompiliert Visual Studio nur noch in dlls und > die exe ist lediglich der Wrapper dafür.
Zeno schrieb: > Programmierer schrieb: >> Der Ausgabetyp: Konsolenanwendung, nix Klassenbibliothek. > In .NET wird alles über Klassen gemacht auch eine simple > Konsolenanwendung. Nur dass für eine Klassenbibliothek kein exe Wrapper erzeugt wird und diese sich auch nicht als einzelne exe Datei, eventuell sogar "Frameworkunabhängig" veröffentlichen lassen. > Programmierer schrieb: >> 2 - Was beim Kompilieren rauskommt, 1 EXE, 1 DLL, 1 PDB und 2 JSON. > Ja das ist bei .NET-Gedöns so. Das eigentliche Programm ist in diesen > DLL's drin. Die EXE ist nur ein Vehikel um die DLL('s) am Ende > ausführen. Ich denke das hat der TO durchaus verstanden, seine Frage war offensichtlich eine andere. Es geht ihm nur darum dass das entsprechende Feld in den Details der Datei anders ausgefüllt wird, weil die anderen Schritte zum erzeugen einer Frameworkabhängigen einzelnen exe Datei hat er ja schon richtig beschrieben. > Am Ende mußt Du noch viel mehr mit Deinem Programm ausliefern als Du > denkst. Wenn Du in Deinem "Hallo Welt" auch nur eine einzige Klasse aus > .NET6.0 verwendest, mußt Du als Programmentwickler dafür sorgen das auf > dem Zielsystem das .NET6.0 Framework installiert ist bzw. während der > Installation mit installiert wird, damit Dein Programm dann auch auf dem > Zielsystem ausführbar ist. Jein, entweder muss das Framework installiert sein oder alles was man aus dem Framework benutzt muss mit im Verzeichnis liegen oder es muss alles was man vom Framework benutzt in der exe eingebunden sein. > Wenn Du wirklich nur eine reine (native) EXE witergeben willst, dann > mußt Du Dir eine andere Programmiersprache/-umgebung suchen, die aus > Deinem Quelltext eine native EXE erzeugt. Natürlich kann man eine "native" exe weitergeben, da drin ist dann ein nativer Loader für die ebenfalls in der exe fest eingebundenen dlls. > PittyJ schrieb: >> Zuerst den Nicknamen von Programmierer auf DAU ändern. Ansonsten ist das >> eine Beleidigung. > Die Formulierung von dem Pitty ist zwar nicht sehr nett, aber er hat > nicht ganz unrecht, denn Du mußt noch viel lernen und von einem > richtigen Programmierer bist Du noch weit entfernt. Ich halte die Frage des TO für mehr als gerechtfertigt, oder welcher Grund fällt dir ein warum im Originaldateiname-Feld in der exe unbedingt der Name der dll stehen sollte? Und ich muss gestehen, dass mir außer der Einsatz von Drittanbieter Tools keine Möglichkeit dafür bekannt ist, was aber wiederum Probleme beim Signieren erzeugen könnte...
Schlaumaier schrieb: > Tim T. schrieb: >> Unsinn, es gibt da keinen Installer. > > https://docs.microsoft.com/de-de/visualstudio/deployment/installer-projects-net-core?view=vs-2022 > > Nur für den Fall das du den mal brauchst. > > Tim T. schrieb: >> Unsinn, das ist kein Installer, immer noch nicht. > > Doch er ist da. ;) MS schwindelt nicht immer. ;) Gott scheiß Hirn vom Himmel, natürlich existiert in VS die Möglichkeit den Installer mit seinem Projekt zu nutzen, aber das hat GARNIX mit der Fragestellung oder dem restlichen Geschreibsel von dir zu tun. > Tim T. schrieb: >> Und wieder am Thema Vorbei. > > Mag ja sein, aber von dir ist auch keine Sinnvolle Antwort. Weil ich für die eigentliche Frage des TO auch keine wirklich befriedigende Antwort habe. Für dich: Es ging offensichtlich nur um den Eintrag im Originaldateinamen-Feld der veröffentlichten exe. Und anstatt das du einfach mal die Finger still hälst, weil du wirklich nach allen Maßstäben keinerlei Ahnung hast, schwafelst du wieder eine Grütze zusammen die dem TO im besten Fall nicht hilft und in allen anderen Fällen Lebenszeit für die Verfolgung eines komplett blödsinnigen Ansatzes kostet.
Tim T. schrieb: > Jein, entweder muss das Framework installiert sein oder alles was man > aus dem Framework benutzt muss mit im Verzeichnis liegen oder es muss > alles was man vom Framework benutzt in der exe eingebunden sein. Ich kenne es so, daß das Framework passend installiert sein muß. Ich habe mal eine Weile an einem etwas umfangreicheren .NET-Projekt mit gearbeitet und da haben wir beim Installieren der Anwendung geprüft, ob das passende Framework auf dem System installiert ist. Wenn nicht wurde das Framework installiert und zwar nach den Vorgaben von MS, also nicht im Programmverzeichnis. Bei uns wurde das Framework einfach mit ins Setup eingepackt und bei Bedarf installiert. Die Applikation selbst war nie eine einzelne EXE und ich wüßte auch nicht wo ich das in VS einstellen sollte, muß allerdings dazu sagen, daß ich die letzten 2 Jahre nichts mehr mit .NET gemacht habe. Ich habe da gerade mal nachgeschaut, lt. MS (https://docs.microsoft.com/de-de/dotnet/core/deploying/single-file/overview?tabs=cli) muß ich dazu in der Projektdatei einen speziellen Eintrag machen damit das alles in eine EXE gepackt wird. Ich würde das so interpretieren, das da von VS aus keine Option vorgesehen ist. Eine Echte EXE ist das aber auch nicht, eher eine Art Archiv, denn der Inhalt wird erst in ein Verzeichnis entpackt und dann erst ausgeführt. Zitatat aus dem verlinkten Beitrag:"... wenn ein Benutzer Ihre einzelne Datei-App ausführt, extrahiert .NET Core-Host zuerst alle Dateien in ein Verzeichnis, bevor die Anwendung ausgeführt wird.". Zumindest bist .NET3.0 war das so. Ab 5.0 wir es lt. MS direkt ausgeführt - vermutlich nur in den Speicher entpackt. Eine echte native EXE ist das in meinen Augen nicht. Die resultierende EXE ist wohl eher ein Container für die App.
Angehängte Dateien:
-
Eigenschaften.png
17 KB
Ich denke, das ist durch das Betriebssystem bedingt, also durch Windows. Das zeigt in den Details auch die Abhängigkeiten an. Anbei mal ein Bild von einer anderen Sprache, die ein Interpreter ist und die Runtime Prfrun32.exe in die Original-Exe mit einbindet. Also beim Compilieren zu einer eigenständigen .Exe. Dort wird ja auch die Prfrun32.exe vom compilierten Bytecode beim Start aufgerufen.
Also ich habe es jetzt mal getestet, mit dem .NET 4.72 und 4.8 Framework wird keine DLL erstellt und ich kann dann einfach die EXE aus dem Release Ordner nehmen. In der Datei stimmt dann auch der Orginaldateiname. Es ist also nicht wie von mir zuerst vermutet von der Version des VisualStudios abhängig sondern von der Version des verwendeten .NET Frameworks. Aber gibt es jetzt eine Möglichkeit das Feld auch bei Verwendung von .NET 6 irgendwie zu ändern?
Angehängte Dateien:
-
Assembly_Name.png
2,4 KB
Ok, ich habe jetzt rausgefunden das der Name im Feld Orginaldateiname immer der Assembyname ist. Allerdings wird wohl immer .dll angehangen egal ob man schon eine Endung vorgibt oder nicht.
Angehängte Dateien:
-
Pb.png
13 KB
Da gibt es wohl immer bessere Möglichkeiten, die Abhängigkeiten zu verstecken. Wenn ich nun ein PureBasic - Programm nehme, sieht man keine Abhängigkeiten mehr. Das ist eine native .exe. Der PB-Compiler generiert reinen Assembler-Output und schickt diesen durch den freien, kostenlosen mitgelieferten FASM. Der produziert dann eine reine native .exe. Es war ja in der Vergangenheit (Anfang Windowszeitalter und vor .Net) so, daß man bei VisualBasic die VBRUNXX.dll (XX = Versionsnummer) mitgeben mußte. Wenn man diese ins Systemverzeichnis kopierte, konnten alle Anwendungen, die mit der richtigen Version von VB erstellt wurden, aufgerufen werden. Das war damals auch bedingt durch den knappen und auch teuren Arbeitsspeicher. Jeder weiß, daß man eine DLL bei Progrmmstart laden und bei Programmende entladen kann. Damit hatte man beim Aufruf mehrerer VB-exen einen viel kleineren Speicherbedarf (Multitasking). Heutzutage wird der Spieß oft einfach umgedreht : Die Runtime startet (bei VB-Net läuft sie vielleicht schon beim Windowsstart ?) und ruft das vor-compilierte Programm auf. So ähnlich ist es auch bei meinen Profan-Programmen. Die könnte ich auch per Kommandozeile aufrufen : die Quellcodedatei -> Profan.exe quellcodedatei.prf die vorcompilierte Bytecodedatei (.prc) -> prfrun32.exe bytecodedatei.prc Sowhol der Interpreter (Profan.exe), als auch die Runtime (Prfrun32.exe) sind quasi Interpreter. Wenn es da ein Update gibt, bekommt man immer beide zugeschickt bzw. kann es downloaden. Das ist mal meine Interpretation des ganzen.
:
Bearbeitet durch User
Heinz B. schrieb: > Das ist eine native .exe. Der > PB-Compiler generiert reinen Assembler-Output und schickt diesen > durch den freien, kostenlosen mitgelieferten FASM. Der produziert > dann eine reine native .exe. Das kann man eigentlich mit jeder Programmiersprache so machen, wenn man den passenden Compiler hat. Das ging sogar mit dem bekannten QBasic. QBasic-Programme wurden ja via QBASIC.EXE also dem Interpreter gestartet. Es gab allerdings auch einen Compiler der aus dem Basicprogramm eine richtige Exe gebaut hat. Bei dem von Dir angeführten Profan, was ja eine basicähnliche Sprache ist, ist es ähnlich. Java und C# arbeiten mit vorcompiliertem Bytecote, der dann vom JIT Compiler erst zur Laufzeit in ein lauffähiges Programm übersetzt wird. Das hat Vor- aber auch Nachtteile. Vorteil ist das das Programm prinzipiell plattformunabhängig ist, solange man keine spezillen OS Funktionen nutzt. Man braucht außer dem vorkompilierten Bytecode halt einen passenden JIT Compiler mit Runttimeumgebung. PS: Wie man das mit C# in eine einzige EXE bekommt hatte ich hier Beitrag "Re: Orginaldateiname Visual Studio 2022 App" kurz angerissen. Scheint den TO aber nicht zu interessieren.
Da gab es sogar eine QBasic.Lib, die man mit dem freien MS-DOS Linker per Batchdatei einbinden konnte. Libs gibt es ja heute noch. Damit meine ich nicht die Definitionsdateien im Klartext, sondern die Funktionen, die in Maschinencode in den Libs gebunden sind. Wenn man etwas tiefer in die Materie einsteigt, weiß man dann auch den kleinen Unterschied zwischen so einer .Lib und einer DLL. Im Grunde sind die eigentlich identisch. Bei einer .Lib wird der Maschinencode der Funktionen beim Erstellen der .exe direkt vom Linker eingebunden und die Referenzen aufgelöst. Die Funktionsadressen werden dabei schon fest in die .exe verdrahtet. Eine DLL wird erst zur Laufzeit eingebunden. Dabei sind die Funktionen der DLL in einem Pool fest verdrahtet und können erst nach dem Laden der DLL aufgerufen werden. Wenn man mal so eine DLL genauer mit einem Tool anschaut, wird man feststellen, daß das Instanzhandle der DLL und die Funktionsadressen der Funktionen bei jedem Laden der DLL identisch sind. Die verhält sich quasi wie eine .exe, die an eine feste Adresse im Arbeitsspeicher geladen wird. Da mein Profan solche Funktionalität für DLLs besitzt (ImportDLL und ImportFunc), hatte ich das schon öfter ausprobiert. Bei JAVA sind das auch oft die .Jar Dateien und die zugehörigen Defintionsdateien im XML-Format.
Heinz B. schrieb: > Eine DLL wird erst zur Laufzeit eingebunden. Dabei sind die > Funktionen der DLL in einem Pool fest verdrahtet und können > erst nach dem Laden der DLL aufgerufen werden. Nein das stimmt so nicht ganz. Ich kann eine DLL statisch oder dynamisch einbinden. Im ersteren Fall muß die DLL vorhanden sein und die Funktionen die vom Programm aufgerufen werden müssen in der DLL vorhanden sein, ansonsten kann das Programm nicht starten. Bei einer dynamisch geladenen DLL kann ich den Zeitpunkt des Einbindens selbst bestimmen. Dazu prüft man zuerst ob die DLL als Datei vorhanden ist. Danach wird diese geladen, wobei man ein Handle auf diese DLL bekommt, über das man dann die Funktionen DLL aufrufen kann. Und auch hier kann man zuvor prüfen ob die gewünschten Funktionen überhaupt vorhanden sind. Das dynamische Einbinden der DLL hat halt den Vorteil, das man das Programm auch bei nicht vorhandener DLL trotzdem benutzen kann. Es stehen dann halt die durch die DLL bereitgestellten Funktionen nicht zur Verfügung, was man aber programmtechnisch einfach abfangen kann.
Beides ist dynamisches Einbinden, der Unterschied liegt nur darin, wer das Einbinden vornimmt. Was Du "statisch" nennst, ist statisches Linken mit der zur DLL gehörenden Importlibrary. Das sorgt dafür, daß im Exe-Header (bzw. einer Tabelle dort) stehende Referenzen auf DLLs vom Programmlader aufgelöst werden, bevor das Programm gestartet werden kann. Das erzeugt die allseits bekannten Fehlermeldungen à la "DLL xy nicht gefunden" oder "Prozedureinsprungspunkt yz in DLL xy nicht gefunden".
Ob man die DLL beim Programmstart oder erst dann, wenn man die Funktionen braucht, einbindet ist doch wohl egal. Da gibt es vom Prinzip her keinen Unterschied. Die DLL muß in beiden Fällen ja vorhanden sein. Das Programm kackt ja erst ab, wenn die entsprechende Funktion der DLL aufgerufen wird. Und ob das nun sinnvoll ist : >Das dynamische Einbinden der DLL hat halt den Vorteil, >das man das Programm auch bei nicht vorhandener DLL trotzdem benutzen >kann. Es stehen dann halt die durch die DLL bereitgestellten Funktionen >nicht zur Verfügung, was man aber programmtechnisch einfach abfangen >kann. Entweder schreibe ich mein Programm so, daß ich die Funktionen selber programmiere und die DLL gar nicht erst brauche oder ich nutze halt die Funktionen einer DLL. Wenn, dann sollte man erst abfragen, ob die DLL da ist und geladen werden kann. Das ist das gleiche, wie bei einer Datendatei, die ein Programm benötigt. Da frage ich auch zuerst ab, ob die Datei existiert und handle dementsprechend. Das nennt man guten Programmierstil und hat nichts mit statisch und dynamisch zu tun. Statisch kann man eine .Lib oder .obj einbinden, dynamisch eine DLL. Daran sehe ich, daß du den Unterschied zwischen .lib und DLL nicht kennst. Wenn man das ganz gut mit der DLL machen will, bindet man diese schon vorher als Ressource in die .exe und schreibt sie bei Programmstart, bzw. Abfrage, ob sie da ist, in den Startordner, wo auch die .exe liegt oder ins Systemverzeichnis. Die Erfahrung habe ich mehrmals bei meinen Usern gemacht, die dann anriefen, weil sie die DLL gelöscht hatten und mein Programm nicht mehr ging. Seitdem wird bei mir immer abgefragt, wenn ich eine DLL mitgebe.
:
Bearbeitet durch User
Heinz B. schrieb: > Entweder schreibe ich mein Programm so, daß ich die Funktionen > selber programmiere und die DLL gar nicht erst brauche oder ich > nutze halt die Funktionen einer DLL. Nö. Nicht weit genug gedacht. So eine DLL kann auch z.B. ein Plugin für irgendeine Funktion sein, und je nach Aufwand unterschiedlich viele Funktionen zur Verfügung stellen. Und wenns die DLL nicht gibt, werden die Funktionen halt nicht angeboten.
Heinz B. schrieb: > Ob man die DLL beim Programmstart oder erst dann, wenn man die > Funktionen braucht, einbindet ist doch wohl egal. Nein, eben nicht. Beim statischen Einbinden kann das Programm nicht starten, wenn die DLL nicht vorhanden ist, es kommt genau zu dem Fehler wie es DerEgon beschrieben hat. Beim dynamischen Aufruf wird die DLL nur eingebunden, wenn man die Funktionen wirklich benötigt. Klassisches Beispiel sind Plugins, die Programme mit zusätzlichen Funktionen ausstatten. Benötigt werden diese für die Grundfunktionen des Programmes nicht. Zudem kann man dynamisch geladene DLL's auch wieder aus dem Speicher entfernen, wenn man sie nicht mehr benötigt und so den Speicher für andere Dinge freigeben. Ich habe selbst ein umfangreiches Programm geschrieben, in welchem ich ausgiebig Gebrauch von dynamisch geladenen DLL's machen. Wenn ich beispielsweise keine Temperaturen mit einem speziellen Gerät erfassen muß, dann brauche ich die ganzen Routinen für das Handling des Temperaturmessgerätes nicht, demzufolge wird wird die DLL die das erledigt nicht geladen. Wenn ich keinen Report erstellen muß benötige ich auch nicht die Reportfunktionen, die ebenfalls in einer DLL abgelegt sind. Jede DLL in diesem Programm hat spezielle Aufgaben, die ich auch nur in speziellen Fällen benötige. Wenn ich schon bei der Installation des Programmes sicher sagen kann, das einige Programmfunktionen mit Sicherheit niemals benötigt werden, dann werden die entsprechenden DLL's auch nicht installiert und das Programm funktioniert dennoch wie gewünscht. Mit dem dynamischen Laden der DLL können auch jederzeit die Programmfunktionen erweitert werden. Der Programmierer muß hierfür nur ein paar Schnittstellen kennen und kann so eine neue Programmfunktion hinzufügen. Dabei ist es sogar ihm überlassen in welcher Programmiersprache er sich dabei austobt. Heinz B. schrieb: > Entweder schreibe ich mein Programm so, daß ich die Funktionen > selber programmiere und die DLL gar nicht Nö Du hast den Sinn nicht erkannt und machst damit dein Programm unnötig unflexibel. DerEgon hat es hier Beitrag "Re: Orginaldateiname Visual Studio 2022 App" schon richtig erkannt. Statische Linken von DLL's macht eigentlich nur essentiellen Runtimelibs, prominentes Beispiel die VBRUN300.DLL, Sinn. Bei Programmen deren Funktionumfang von Anfang fest steht, braucht man weder irgendwelche .obj, .lib noch .dll mitzugeben, da programmiert man das einfach in das Hauptprogramm mit rein. Jede zusätzlich notwendige Datei birgt das Risiko, das der Nutzer seine Programmversion abschießt, wenn er versehentlich oder aus Unwissenheit eine erforderliche Datei löscht - was Du ja ganz offensichtlich schon selbst bemerkt hast. Das Problem wird auch nicht daddurch gelöst, das man die Dateien mit ins Programmverzeichnis kopiert, da man sie auch dort löschen kann. Wenn ich alles selbst in der Hand habe, dann sorge ich dafür das das Programm möglichst immer startet und in seinen Basisfunktionen auch funktionsfähig ist, selbst dann wenn Dateien fehlen. Es ärgert mich immer wieder, wenn eine Software nicht benutzt werden kann, weil z.B. eine simple Konfigurationsdatei fehlt. Ich habe das bei meinen Programmen so gemacht, das es dann mit Defaulteinstellungen startet und die Konfigurationsdatei dann aus diesen Einstellungen selbständig erstellt. Das ist relativ wenig Aufwand, minimiert die Supportanfragen und hat sich bei mir in gut 30 Jahren bewährt. Heinz B. schrieb: > Wenn man das ganz gut mit der DLL machen will, bindet man diese > schon vorher als Ressource in die .exe und schreibt sie bei > Programmstart, bzw. Abfrage, ob sie da ist, Bei einer statisch eingebundenen DLL funktioniert das meist nicht, da die DLL-Referenzen im EXE-Header stehen und ich gar nicht erst bis zu meiner Abfrage komme - auch das hat DerEgon richtig beschrieben
DerEgon schrieb: > Und wenns die DLL nicht gibt, werden die Funktionen halt nicht > angeboten. So ist es.
Heinz B. schrieb: > Statisch kann man eine .Lib oder .obj einbinden, dynamisch eine > DLL. Daran sehe ich, daß du den Unterschied zwischen .lib und > DLL nicht kennst. Nein man kann eben auch eine DLL statisch einbinden. Lib's und obj-Dateien spielen vornehmlich zur Compiletime eine Rolle und werden schon während des Compiliervorganges aufgelöst und in die EXE eingebunden. DLL's hingegen können nur zur Laufzeit eingebunden werden, ob statisch oder dynamisch ist erst mal egal.
Zeno schrieb: > Bei einer statisch eingebundenen DLL funktioniert das meist nicht, da > die DLL-Referenzen im EXE-Header stehen und ich gar nicht erst bis zu > meiner Abfrage komme - auch das hat DerEgon richtig beschrieben Aha, gut zu wissen. Ich kenne dann nur dynamisches Einbinden, da bei mir die DLL-Referenzen halt nicht im Exe-Header stehen. Das Instanzhandle und die Einsprungs- adressen der Funktionen werden bei mir erst zur Laufzeit ermittelt, soll heißen, wenn die DLL geladen wird. Damit hat sich dann das Thema für mich erledigt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.