[VC++] include runtime bestanden in programma mogelijk?

[oddish2211]

nu ben ik weer is 'n keer aan de slag gegaan met Visual Studio 2010 om C++ te leren. ik heb geen ervaring met andere talen, behalve een beetje proggen op een arduino (soort van C).

maar nu heb ik een leuk klein programmaatje in elkaar gezet dat een wiskundige berekening doet en daarna de resultaten weergeeft, en hij werkt perfekt Het is een W32 command line programma. maar als ik deze op een andere computer draai krijg ik meteen de melding dat hij MSVCP100.DLL mist (op W7 pc's) en MSVCR100.DLL (op Vista pc's).

okee, even opgezocht, je moet de visual c++ runtime installeren om zo'n programma werkend te krijgen. nu wil ik dit programma, en programma's in de toekomst ook op schoolcomputersdraaien. en daar is de runtime niet op geinstalleerd, kan ook niet. is het mogelijk om alle bestanden van de runtime in het programma zelf te proppen zodat de runtime niet geinstalleerd hoeft te worden?

[ValHallASW]

Je hebt een aantal mogelijkheden. Je kunt allereerst alle benodigde DLLs in de werkmap van het programma zetten. Hoeveel je er dan moet kopiëren weet ik niet; het zou best kunnen dat het er nogal veel zijn. Maar: het kan.

Een ander alternatief is een andere c++-compiler gebruiken. Grote kans dat msvcp60.dll et al. wél op je schoolcomputers aanwezig zijn. Dan moet je alleen wel de compiler van VC++ 6.0 gebruiken (of in de vc++2010-compiler msvcp6 als target instellen, maar ik weet niet hoe dat moet )

[ Voor 10% gewijzigd door ValHallASW op 14-09-2010 09:35 ]

[BoAC]

Static build is volgens mij de beste oplossing: zie deze thread

[.oisyn]

Properties van je project -> C/C++ -> Code Generation -> Runtime Library instellen op een variant waar geen "DLL" in de naam voorkomt ("Multithreaded" voor release, "Multithreaded debug" voor debug)

[MSalters]

"Multithreaded Debug" mag je niet naar schoolcomputers kopieren (debug libs zijn non-redistributable). Maar goed, aangezien daar geen Visual Studio op staat, en ook geen remote debugger geinstalleerd kan worden is de "Multithreaded Debug" build ook niet nodig - debuggen doe je gewoon lokaal en dan werkt de DLL build ook.

Maar het meest simpele is om gewoon die twee genoemde DLLs in dezelfde dir als je EXE te zetten. Dat is de eerste directory waar Windows kijkt om DLLs te vinden.

[ Voor 22% gewijzigd door MSalters op 14-09-2010 12:46 ]

[oddish2211]

en het werkt allemaal, heel erg bedankt

[BoAC]

oddish2211 schreef op dinsdag 14 september 2010 @ 15:36:
en het werkt allemaal, heel erg bedankt

* BoAC is benieuwd hoe je het hebt opgelost

[farlane]

MSalters schreef op dinsdag 14 september 2010 @ 12:44:
Maar het meest simpele is om gewoon die twee genoemde DLLs in dezelfde dir als je EXE te zetten. Dat is de eerste directory waar Windows kijkt om DLLs te vinden.

Sinds WinSXS gaat die vlieger niet meer op en zul je merken dat je standaard niet meer aan dergelijke "xcopy deployment" meer kunt doen.

Zie ook http://blog.kalmbach-soft...stalling-vcredist_x86exe/

[Soultaker]

Ik snap die weblogpost niet. Wat bedoel je precies? Waarom zou die DLL niet uit de huidige directory geladen worden als 'ie nergens anders te vinden is?

(Ik begrijp ook niet dat Windows developers niet gek worden van het gedoe met manifests en dergelijke. Als je die stappen in die post al ziet: kopieer bestandje hier, edit bestandje daar, kopieer files uit de Visual Studio directory hier, delete tokens daar, en dan maar bidden dat alles werkt! Dat is toch geen manier om een applicatie te builden?)

[.oisyn]

Idd, gewoon statisch linken, ben je van al dat gezever af.

@Soultaker: volgens mij zijn de stappen in die post onnodig complex. Je maakt gewoon 1 keer een aangepaste manifest, en je zorgt dat je de juiste libs meedeployed. Of, zoals ik al zei, gewoon statisch linken . Daarnaast moet je niet vergeten dat ze hier ergens omheen proberen te werken. Bij de meeste applicaties met een gewone fatsoenlijke installer, installeer je ook gewoon de CRT redist van VS mee, en heb je ook al dat gezeik niet.

[ Voor 93% gewijzigd door .oisyn op 14-09-2010 18:15 ]

[farlane]

Soultaker schreef op dinsdag 14 september 2010 @ 18:09:
Ik snap die weblogpost niet. Wat bedoel je precies? Waarom zou die DLL niet uit de huidige directory geladen worden als 'ie nergens anders te vinden is?

Applicaties bevatten manifests die aangeven welke dll en welke versies ze nodig hebben. WinSXS zoek die dingen in zijn eigen 'repository' en weigert een applicatie te starten als ze daar niet te vinden zijn. Er wordt dus niet gezocht in het pad van de applicatie zelf, zoals van oudsher wel het geval was.

Het oude gedrag is dus wel te bereiken min of meer.

(Ik begrijp ook niet dat Windows developers niet gek worden van het gedoe met manifests en dergelijke. Als je die stappen in die post al ziet: kopieer bestandje hier, edit bestandje daar, kopieer files uit de Visual Studio directory hier, delete tokens daar, en dan maar bidden dat alles werkt! Dat is toch geen manier om een applicatie te builden?)

Dat klopt.

Bij de meeste applicaties met een gewone fatsoenlijke installer, installeer je ook gewoon de CRT redist van VS mee, en heb je ook al dat gezeik niet.

Kopieren en gaan is anders ook genoeg voor te zeggen. Is ook makkelijker deinstalleren...

[ Voor 11% gewijzigd door farlane op 14-09-2010 18:34 ]

[oddish2211]

.oisyn schreef op dinsdag 14 september 2010 @ 12:01:
Properties van je project -> C/C++ -> Code Generation -> Runtime Library instellen op een variant waar geen "DLL" in de naam voorkomt ("Multithreaded" voor release, "Multithreaded debug" voor debug)

dit was de oplossing