Moin, ich habe mit VS 2013 eine C++-Konsolenanwendung geschrieben. Diese funktioniert auch soweit. Mein Problem ist es, wenn ich die .exe auf einem Rechner ausführen möchte, auf dem nicht VS 2013 installiert ist klappt dies nicht. Zwei dlls fehlen; ich hatte versucht die beiden dlls per Hand in System32 zu kopieren, jedoch startet das Programm dann immer noch nicht. Gibt es eine Möglichkeit, Programme in VS zu schreiben, die auch auf Rechnern ohne die Entwicklungsumgebung ohne Probleme funktionieren? Gruß
Gast
#3950801
> Gibt es eine Möglichkeit, Programme in VS zu schreiben, die auch auf > Rechnern ohne die Entwicklungsumgebung ohne Probleme funktionieren? Ja, aber das willst Du nicht. Installier auf dem Zielsystem die vcredist, die kommt zusamment mit dem VStudio.
g457 schrieb: > vcredist welche Version davon genau?
Gast
#3950811
> welche Version davon genau?
Die, die Dein VStudio mitbringt. Ob x86 oder amd64 musst Du dann selber
entscheiden. Und nicht vergessen, ein Release zu bauen,
Debug-Executables sind ohne VStudio notorisch schwierig in Betrieb zu
nehmen.
ok, danke für die Infos. Mit VS kann ich ja auch Setups erstellen, gibt es eine Möglichkeit die vcredist darin zu integrieren, sodass sie zusammen mit der entsprechenden Anwendung installiert werden?
Gast
#3950819
> Mit VS kann ich ja auch Setups erstellen, gibt es eine Möglichkeit die > vcredist darin zu integrieren, sodass sie zusammen mit der > entsprechenden Anwendung installiert werden? Ja, das ist die einfachste Methode. Einfach als zusätzliches Paket hinzufügen.
Gast
#3950820
Marco G. schrieb: > Zwei dlls fehlen; ich hatte versucht die beiden dlls > per Hand in System32 zu kopieren, jedoch startet das Programm dann immer > noch nicht. Kopieren != Registrieren
g457 schrieb: > Einfach als zusätzliches Paket > hinzufügen. Wie mache ich das ganz genau, ich habe mir die beiden Pakete als exe von der MS Seite heruntergeladen.
g457 schrieb: > Ja, aber das willst Du nicht. Wieso sollte er das nicht wollen? Das ist eine simple Compiler-Einstellung, und man muss nicht verschiedene von MS identisch benannte vcredist-Varianten auseinanderhalten. Im "Solution Explorer" Rechtsklick auf das Projekt, dann "Properties" aufrufen. Configuration Properties->C/C++->Code Generation Und hier unter "Runtime Library" die /nicht/-DLL-Varianten auswählen. (also /MT bzw. /MTd statt /MD bzw. /MDd). Fertig ist die Laube. Der "Nachteil", daß das so erzeugte Binary geringfügig größer ist als ein von vcredist abhängiges, wird durch die erheblich einfacherer Handhabung mehr als kompensiert.
Gast
#3950841
> Wie mache ich das ganz genau, ich habe mir die beiden Pakete als exe von > der MS Seite heruntergeladen. Das ist der oben erwähnte erste Weg. Dieses Paket (in ∗genau∗ der richtigen Version) auf dem Zielsystem installieren. Alternativ über den Installer: In den Eigenschaften des Installer-Projekts auf 'Prerequisites' (bitte ggf. adäquat übersetzen..) und dort die Runtime hinzufügen. So oder so ähnlich müsste es funktionieren, ist schon eine Weile her dass ich das das letzte mal gemacht hab.
Gast
#3950868
Alternativ kannst du auch die fehlenden .dlls in den gleichen Ordner wie die .exe packen.
Ich habe mal beide Varianten ausprobiert. Am einfachsten ist es, meiner Meinung nach, die Compiler-Einstellungen zu verändern. Ich habe die Pakete in den Setup integrieren und installieren können, hat trotzdem nicht funktioniert. Ich tippe auf das falsche Paket. Danke für die hilfreichen Tipps, die zur Problemlösung beigetragen haben
Gast
#3951372
Microsoft selbst rät von statischem linken ab: "Prefer dynamic linking over static linking It is not recommended to redistribute C/C++ applications that statically link to Visual C++ libraries. It is often mistakenly assumed that by statically linking your program to Visual C++ libraries it is possible to significantly improve the performance of an application. However the impact on performance of dynamically loading Visual C++ libraries is insignificant in almost all cases. Furthermore, static linking does not allow for servicing the application and its dependent libraries by either the application's author or Microsoft. For example, consider an application that is statically linked to a particular library, running on a client computer with a new version of this library. The application still uses code from the previous version of this library, and does not benefit from library improvements, such as security enhancements. Authors of C/C++ applications are strongly advised to think through the servicing scenario before deciding to statically link to dependent libraries, and use dynamic linking whenever possible." http://msdn.microsoft.com/en-us/library/ms235316(v=vs.80).aspx