Printable View
After I finish my project, how can I make my own instalation. I know, there are a lot of software for that, but how can I make my own. So, I have one EXE and a few files (doc, txt, bmp,...). How to put all that in one ExE, and after I run that he will extract all files, just like other setups do.
Hope someone know :wave:
Use the Package&Deployment Wizard that comes with VB, but it's very dated. Or you can use NSIS, or Inno Setup. I prefer NSIS as it's free and scriptable, so you can create very customized installers.
Check this: Click Here (Link) :wave:
That's it. How to make OWN installer, not using otherQuote:
Originally Posted by akhileshbc
Jarane, using VB6 for an installer might not be the best idea, as VB6 requires the VB6 Runtime, if a user deosn't have it installed they wont be able to run the installer you made and would get an error. Using the other installer creators will solve that. ;)
Properly installing programs isn't as trivial as some people make it sound.
Folders have to be created, permissions often must be set on them, files get copied to appriate locations, components need to be registered, shortcuts need to be created, and often even more has to be done like updating INI/config files used by the program to locate files or databases after they're put into place. This doesn't even begin to get into other things like DCOM configuration or adding firewall rules.
Most programs people write are pretty simple though, and only need to do a few of these things.
The PDW does not create a single-file package. It also requires the VB6 runtime since the bulk of the process is performed by setup1.exe which is itself a VB6 program. This is why there is a setup.exe "bootstrapper" that runs first (installing the VB6 runtime and then running setup1.exe to install your program).
One option is to post-package the outputs from the PDW into a single file that is a self-extracting archive. You need a self-extractor with the option of extracting to a temporary folder and then running a designated EXE from among the extracted files, then it really should clean up the temporary folder.
The PDW was superceded once Windows Installer came on the scene. This was introduced with Office 2000, and was an installable option for Windows NT 4.0, 95, 96, and 98SE. It became part of the OS with Windows Me and 2000.
Microsoft addressed this for VB6 users by providing a free Visual Studio 6.0 Installer tool. There was a 1.0 designed for Windows 9x, and then a version 1.1 that replaced it for all operating systems.
Using Windows Installer you typically package your application into a single .MSI file. This is a registered file type, so users can just double-click it to invoke a default instalaltion. Windows Installer addresses many issues that required hand-fiddling before, but VSI 1.1 was not capable of using all of the options Windows Installer supports.
There are several free and pay 3rd party packagers for Windows Installer. Many of them are more complete than VSI 1.1 is and automate many things you might otherwise have to do by hand using the Orca.exe tool (which is used for editing .MSI files - which are actually databases).
Many people use 3rd party packagers that still rely on outdated "scripting" techniques and calls to the aging Setup API like the PDW does. These can often be made to work right on recent Windows versions with some fiddling. Starting with Vista there is a "legacy scripted installer heuristics" process Windows goes through to try to detect these when they run. Then Windows can apply various appcompat shims to try to make the legacy setup work properly, though sometimes it just takes process elevation.
I don't recommend these approaches myself. I see people trying to copy/paste script snippets like they were magical incantations. Then we usually see their cries for help in the Application Deployment forum here.
Packaging and deployment can be a complicated topic. You should expect to make a time investment studying this subject before being good at it. People routinely get themselves in trouble using even the PDW because they don't understand the issues involved.
When the world was younger and the PDW was new it "understood" the rules on Win9x. Those rules have changed and gotten more complicated since those early days. The PDW can be updated to be smarter by manually updating component .DEP files and VB6DEP.INI, but to find the necessary changes you'll have to wade through 12 years of Microsoft Knowledge Base articles on the subject.
Even then you have to go in and customize setup1.exe though (Microsoft provided the source, look in your PDW folder under Program Files). The problem is some setup packages have to be aware of the Windows version they're installing onto, and do different things or deploy different versions of dependencies.
Many of these issues are covered here in the Application Deployment forum's FAQ thread.
This is a trivial task, and the amount of misinformation here is deafening.
Simply build your package as normal using the PDW wizard, and then use Winzip to create a self-extracting executable from the output files. There is an option in Winzip to create a "self-extracting ZIP for software installation." When you use this option, it asks what program to wait for to complete. Choose "Setup1".
Its just that simple.
LONG LIVE VB CLASSIC!
It is if the application you are building the installer for is trivial. But even then there are pitfalls.Quote:
Originally Posted by Zaxbowow
- What if you have online components that need to be checked and downloaded during installation?
- What if you application has multiple exe files, one of which needs to be started after the installer, but must not run with Admin privileges (Vista and W7)? Installers by default get elevated to admin level (based on keywords, or if you manifest them), and when elevated application launches another one, that one is immediatelly launched as admin too, there is no way to 'downgrade' the privileges.
There are more, these are just some I dealt with very recently.
Moved To Application Deployment