Ok, the time has come for me to write an installation program. I have to install two bits of software: DirectX (which is easy, as I can copy the example one from the sdk), and some vb runtime files for my partner''s part in the project (he insisted on vb). The problem is, his program needs a very specific release of the runtime files. So I first need to check if the runtime files exist on the target computer - what''s the best way to do this, and I then need to find the version of the vb runtime dll provided a previous install exists. However I think I am right in thinking that vb programs are version specific - if this program was developed for vb runtime 6 service pack 4 then it will *only* run with that installed. And once all this is done, how can I suppress the vb runtime install package restarting the machine, as I''d like to install directx and the vb runtime package in one go. Any advice would be helpful . r. "The mere thought hadn''t even begun to speculate about the slightest possibility of traversing the eternal wasteland that is my mind..."

quote:

---

Original post by Fresh

Ok, the time has come for me to write an installation program. I have to install two bits of software: DirectX (which is easy, as I can copy the example one from the sdk), and some vb runtime files for my partner''s part in the project (he insisted on vb). The problem is, his program needs a very specific release of the runtime files. So I first need to check if the runtime files exist on the target computer - what''s the best way to do this, and I then need to find the version of the vb runtime dll provided a previous install exists. However I think I am right in thinking that vb programs are version specific - if this program was developed for vb runtime 6 service pack 4 then it will *only* run with that installed. And once all this is done, how can I suppress the vb runtime install package restarting the machine, as I''d like to install directx and the vb runtime package in one go. Any advice would be helpful .

r.

"The mere thought hadn''t even begun to speculate about the slightest possibility of traversing the eternal wasteland that is my mind..."

---

This might help. Have him use his project and run the package and deployment wizard to create a setup. This packages the runtimes and everything else required by the installation into a .CAB file, (make sure he compiles to Native Code by the way). You should then just have the install search for the runtime files, then do a file compare on the ones in the package(can be included in a packing list showing the file''s modified date/time) to the ones on the system and if the ones on the system are older then overwrite them. This could help you avoid what''s known as "DLL H*LL". That way you don''t overwrite NEWER files as some other people''s installations do when they don''t bother to compare.



BeS
It''s Da BOMB Baby!!!
. o O ~
A little nonsense now and then,
is relished by the wisest men
~ O o .
-- Willy Wonka