Dear all expert programmer,
I want to copy my application (.exe file) into flashdrive and run if from flashdrive without install. Please tell me how to make it to portable application.
Thank you for all answer.
Printable View
Dear all expert programmer,
I want to copy my application (.exe file) into flashdrive and run if from flashdrive without install. Please tell me how to make it to portable application.
Thank you for all answer.
The canned answer: you don't. VB executables rely on VB runtime files which must exist on the target system. If your app uses any references to ocx's or dlls, then those too must be on the system, any active-x DLLs are also required.
You may find some posts here and elsewhere describing methods of self-registering the required files if you absolutely want to go that route, but I wouldn't recommend it because there is much room for error, including overwriting/corrupting more current versions of the user's OCX/DLL with the "older" copy you may have on your flash.
Well, most required drivers would need to be placed in the windows system file.
But, if you use and installer package, it seems like you could just tell it to install to the thumb drive.
That would put the exe itself on the drive.
You'd need to do the install on each comp that would use the drive.
I haven't tried it, but it seems like it'd work.
The failure of Win2K-style DLL/COM Redirection (using .local files) and the need for lightweight application installation led to the introduction of a new .manifest file based isolated application technology in Windows XP. This was not mature until XP SP2, but by that point registration-free COM became a solid reality.
So within some strict limits it is quite possible to create portable applications in VB6. Here are the fundamental limitations:
- If your application uses any external COM/ActiveX libraries (DLL, OCX) it will only run on Windows XP or later. In some cases Windows XP SP2 or later is required.
- The VB6 runtime components require installation, so you must test to be sure your program runs properly under the version of the runtimes shipped with Windows XP and all later versions a user might have upgraded to.
- DCOM and ActiveX EXE require registration, so applications that use them cannot be made portable.
- Some system components such as parts of MDAC/DAC and some versions of MSXML cannot be isolated. So target ADO 2.5 and use MSXML 4.0 and in general be cautious about the things you shouldn't even be deploying with a formal installer.
So we have what we need now.
You only need to limit your target OSs to XP SP2 and later, be sure you test against the VB6 SP5 and SP6 runtimes, don't rely on ActiveX EXEs, and do not try to package and deploy things that can't be isolated.
Then you have to create an isolated application package from your compiled VB6 Project.
This is what sends people off into the wilderness wringing their hands or desperately trying hackish things like .local DLL Redirection or worse yet runtime registration of components. The latter can be quite hazardous, leading to broken COM registration and one of the nastier forms of DLL Hell.
The problem is that even though reg-free COM was developed with VB6 in mind Microsoft never provided any tools for VB6 developers. The move to .Net was in full swing by then and the VB franchise had already been killed. There are a few tools in different VS.Net versions for creating the required isolation manifests. Sadly these are geared toward .Net/VB6 interop scenarios though, and it is far from obvious how to use them on a VB6 program.
There are a few 3rd party tools that might help. Side-by-Side Manifest Maker is an advanced commercial tool geared toward very general application. Make My Manifest is a simpler freeware tool geared toward simple VB6 EXE projects. Current InstallShield products also mention reg-free COM.
I have a vb exe on a U3 flash drive. The flash drive also contains the installler.
The exe when started first looks to see if it is being started from the flash then for a special iso image on the cd portion of the U3 if not found the program will not run. The installer puts a Run Flash Drive.exe in program files and installs start menu and desktop shortcuts and the required ocx's and runtime files. The hardest part was replacing the iso image on the cd portion with a custom one. This has been done so the program will not run unless the Usb Flash is purchased from me
But portable applications do not install or require admin rights by definition. They never leave pieces behind on disk or alter the registry.
Where "application's installation directory" is on the removable device.Quote:
In order to make properly portable applications, software applications must leave the computer they run on exactly as they found it when finished. This means that the application cannot use the registry, nor store its files anywhere on the machine other than in the application's installation directory. When installed to removable media, a program would need to store settings in an INI file (or similar configuration file) rather than in the registry.
Portable application
I assume that the target machine has VB6 runtime installed.Quote:
Originally Posted by standardusr
I just copy my application and all the dependent OCX/DLLs on to a folder in it.
This usually works, because the VB6 applicaitons look in their own folders first and then the system folders for dependencies.
Also keep a copy of the VB6 runtime on your thumb drive handy, just in case the target machine doesn't have VB6 runtime installed, as this is a must for our applicaiton. So in such a situation, you can first install the VB6 runtime before running your application.
In case this doesn't work, you have no option other than carrying an installer for your application too on your thumb drive ;)
Pradeep :)
This is a poor idea. When the program is run the component libraries will be registered in this funky location. When the folder is moved or removed (or if on removable storage, removed) you will leave broken registrations behind. Try it and see!Quote:
Originally Posted by Pradeep1210
This is why we have application isolation and registration-free COM now.
NO,Quote:
Originally Posted by dilettante
Though your application will use its own copy or the DLL/OCX and not the one in the system folders, it will not disturb them in any way (unless you are doing it from code inside your applicaiton).
The component libraries are not registered by themselves unless you do it via code or the REGSVR23 application. Nor do I intend/recommend to disturb the system folders.
Pradeep
Sorry, but I just retested an application with the components in the same folder on a clean system. Running the EXE resulted in the components being self-registered. This is why you never want dependency libraries in the application folder.
Strange :rolleyes:Quote:
Originally Posted by dilettante
I have done this many times and never faced problems of DLLs registering themselves.
Didi you by any chance run your program in the VB debugger? Doing so, might cause problems as the Visual Studio automatically registers the dependencies for you.
Pradeep
Have you actually checked properly?
It happens (I've seen it myself), and has been well proven before. I think there are a few articles at Microsoft.com which explain it.
dilettante is extremely knowledgeable about installation issues, and is well known for good research - making a mistake like also using the IDE is not something I could imagine.
Yes, I've had been doing this for about 5 years (before switching over to .NET) and never faced problems of components self registering themselves.
Though some of the components won't work unless you register them (by putting in system/system32 folder and registering them manually). Bit that's a different thing all together.
Pradeep
There is a big difference between "never having a problem" and "never causing a problem".
What dilettante is referring to is problems that you cause for other programs - users of your program would simply blame the other programs, as they are the ones that show the errors.
This means that you wouldn't know about it unless you specifically checked for it, or it was on your computer and you thought about the connection (if it wasn't in a short time frame since deleting your program folder, you probably wouldn't).
Since I was the incharge if the dept., and all software related problems where routed thru me, I should have known if such a problem ever happened.
Does this happen with all components or specific ones? It could be possible I never used those which cause problems.
Can you please point me to some articles that describe this?
I would love to be able to give you a link to some Microsoft KB article or something that describes how a VB6 program calls DLLRegisterServer in unregistered COM libraries that it finds. There doesn't seem to be such a thing, however.
There are web pages that cover this experience though, mostly at developer forum sites like this one. Here is one such discussion: How to use OCXs without registering them?
The easiest way to see this is to just try it. Create a small VB6 program that uses some external library like an OCX. Compile the EXE and then copy the EXE and the referenced OCX into some folder on another computer that does not have VB6 installed and preferably has never had this OCX installed. Run the EXE (which may or may not run properly but should not see "cannot create object" errors). Terminate the EXE and then run regedit and do a find on the name of the OCX file.
You will find that the OCX has been registered.
You can try this using a MaskEdit control, which is a simple single OCX with no other subdependecy to deploy. Searching the registry after running it reveals:
And that is just the first "hit" the find operation stops on.Code:Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{83730EE4-6C46-11CF-A524-0080C77A7786}]
@="MSMask General Property Page Object"
[HKEY_CLASSES_ROOT\CLSID\{83730EE4-6C46-11CF-A524-0080C77A7786}\InprocServer32]
@="C:\\Documents and Settings\\IETest\\Desktop\\regtest\\MSMASK32.OCX"
If deploying ActiveX components were as simple as placing them next to their client applications Microsoft would have suggested it long ago. What I suspect but do not know is that somewhere along the line they thought it might save a lot of trouble to modify the runtime to punt on attempted loading of objects from unregistered classes.
It appears that if the necessary library is found via DLL serch the runtime calls the library's DLLRegisterServer entrypoint (which is what running regsvr32 does). It might be interesting to run Process Monitor before starting such an EXE to see all of the gyrations that the program goes through.
The problem is that you now have a component registration that points to a copy of the library in a possibly transient application folder. If you move or remove this folder, any other program that subsequently tries to load via the registered information will fail.
I'm still wondering if something is wrong with my suggestion?
Just use an installer to put any needed dll's or ocx's in the system folder.
But tell it put the program in a folder on the thumb drive.
Thanks a lot dilettante. That was really interesting and enlightening :thumb:
The main idea behind a portable application is to be able to take the program from computer to computer and run it without requiring installation or admin rights and without leaving anything behind.Quote:
Originally Posted by longwolf
These might include an email client, addressbook or PIM, web bookmark keeper, photo album, etc. It lets you carry this material around using it from a cyber cafe or a friend's house or even between your desktop and laptop machines. Since programs alone aren't too useful, you usually install portable applications onto read/write media like a flash drive instead of a CD-R so you can update data. See What is a portable app?
If you install as you suggest you are bound to one computer, and may as well have installed to the hard drive.
What if you made two exe's, the main app and a loader.
The loader wouldn't need anything but the vb runtimes (or maybe it could be in some other language).
It's called from the program shortcut and checks to see if the dependencies of the main app are installed, if not it calls the installer.
If they are there, it calls the main app and closes itself.
Might not be a true portable app, but if there's no other way in vb6.....
As far as the personal data, it'd be stored in the program's folder on the thumb drive.
Just looked at the 1st post again, he want No Installing.
Looks like he needs another language.
No, you're just limited to XP or later and you use reg-free COM. Works great.
I haven't read/digested dilettante's posts, but I surely will.
If you will be shoving your flash drive into PC's that are running Windows XP or 98SE, or maybe even Vista, you will find that the VB6 runtimes will already be present. (In the 98 PC's surely some other app has installed them by now.)
95% of my programs never get installed. The user just creates a folder in their C drive, and places my exe (not an installer) into that folder. Then a double click just runs the program.
I believe it would be the same if they had a folder on a thumb drive instead.
I get away with this, by NOT having any dependencies in my programs.
I sometimes use User Controls (.ctl) sometimes, and they too do not require my program to be installed.
The other 5% of my programs may be using Data Bases, or the free SGrid2.
What I do for those is give the user a stand alone installer that has the controls/references required. That program(installer) has no source code, and is run once only.
Once that has been run, I can provide other programs that have those dependencies, and those programs do not require installing.
I asm pretty sure they too could be placed in a thumb drive (if you can get the user to run the stand alone installer, once.).
HTH,
Rob
I posted a longer reply a wee while ago. It may have got lost, as I had to log in during the 'posting' process ?
If your pgm has no dependencies, then it should work fine in XP, Vista (who knows ?), and 98.
In 98 surely some other pgms would have popped the VB6 runtime in by now.
If your pgm has dependencies, then try using User Controls (.ctl) instead.
I never install any of my programs.
The 5% of my pgms that have dependencies/references, I handle by making a stand alone installer, which has no source code, and only needs be run once.
HTH,
Rob
PS I will be reading dilettante's posts with interest
It was posted, it just wasn't visible until it could be manually checked (this happens for some posts by new members, as part of our spam protection).Quote:
Originally Posted by Bobbles
this what i do (although it is illegal to remove certain apps from your house, like ms office. that's why i leave them at home). I strongly recommend that if if you do this, KEEP THEM AT HOME! this just saves multiple installations.
go to [drive]:\Program files
[drive] represents where your programs were originally installed. usually C:\
copy the ENTIRE folder for the program you want made portable (e.g. if you want to make myProgram portable, copy the folder named myProgram). now paste it onto your memory stick. test it. some programs will not work this way, as some will store files in multiple directories. just don't leave the house with it. you may be breaking the law. the programs i write are free and i don't care if you do that. although, my programs for some reason don't install in the program files folder.