Printable View
I am trying to make my vb project run on a U3 flashdrive. I have included the vb runtimes on a flash drive. I have a function that will register them if the are not
registered by sending the function the file name.
Do each vbruntime files need to be registered?
Can a runtime be registered both the system32 and the flash drive and have the same name ?
Never register component libraries that are located on removable media. This is a good way to trash somebody's system, which is part of why System File Protection had to be implemented to protect critical Windows components.
Many components can be isolated through Registration Free COM in WinXP and later. As far as I have been able to determine Windows prevents this for VB6 runtime components because they are considered system components these days. Since this is true as long as you're careful to test with the VB6 runtimes shipped on XP (VB6 SP5+, msvbvm60.dll ver. 6.0.92.37) you don't need to worry.
Anything older than WinXP requires component registration or a hairy hack, so I'd just write off pre-XP versions of Windows for portable applications anyway.
The only other workaround I can think of involves some 3rd party virtualization packager like Thinstall. It might let you put later runtimes into the package.
If you've read the "U3 Deployment Kit" document from SanDisk's U3 Developer site you'll see this is precisely what they recommend, use: no COM, Reg-Free COM, or Thinstall (or equivalent). The only alternative is to register/run/unregister on each program invokation, which can have deleterious effects on the host system if not done carefully. Even done right you may break other applications or system functionality until you have completed cleanup. If your changes cause a crash cleanup may not be possible.
I'll add that by sticking to XP+ Windows versions, using Reg-Free COM, and properly testing you can run portably from non-U3 flash devices, USB hard drives, or CDs as well.
Just as with U3 though you'll want a wrapper process that temporarily moves your application EXE, component libraries, and data files to the hard drive before running the main program. And then cleaning up afterward as well.
It is also possible to relink a compiled VB6 EXE, DLL, or OCX to "run from CD" which tells Windows to copy it to the system disk cache and hold it for use there until program termination. This usually is not practical if you use precompiled DLLs from other sources in your application though. Thus it is best to create temporary copies on the hard drive and clean up afterward.
It is also important to consider the versions of other system components when developing and testing. For example XP shipped with ADO 2.7 so you must target that release or earlier. Other components didn't arrive even in XP until SP1, SP2, or SP3 and many of them are not redistributable.
Here's what i am trying to do:Quote:
Originally Posted by dilettante
I sell roof estimating software. My installer does not install files if they are present. The flash drive would be for only registered users and have to be plugged into registered desktop every 30 days or will not run. I am trying to put my program on the Flash so a roofing company can give the flash to a estimator to use on a laptop in the field. This software produces .bid files.
It then could be plugged into the main computer and the bids copied or transferred to the main computer. You are throwing me a bunch of curves I did not anticipate. I am beginning to think it may be be better to put the installation software on the Flash and only have the exe on the flash. What do you think?
Well if it would work for you the simplest thing is probably to have the flash drive carry an installer of some sort and the data to be brought back in. Then if the program hasn't been installed it could be.
I suppose you're using some other file that carries your 30 day activation code and that would still be ok on the flash drive.
I doubt aynone is really seriously using a laptop with anything older than WinXP these days though. So you might get by relying on the system's copy of the VB6 runtime component files.