[RESOLVED] How to keep folders and their names, in the setup packager???

[ThEiMp]

I am trying to get the setup packager. That comes with: VB6 Enterprise Edition. To keep files, in their folders. The app works without the folders, but how am I, meant to get the app to have folders, in it???

[dilettante]

You are probably trying to describe the Packaging and Deployment Wizard that was the original packager released with VB6. It is a slight refinement of the older setup tool provided with VB5 and Office 97 Developer Edition.

When you run the PDW one of the early panels gives you the option of adding files to the package. This is where you might add data files and such. A subsequent panel allows you to set file locations for each file, and this is where you place the files into folders.

Some of this can also be done by editing the Setup.lst file and re-running PDW against it. A brief overview is at Description of Setup.lst sections, and there are other KB articles out there with more details in them.

Here is the [Setup1 Files] section of a sample Setup.lst file. Note that these follow the format for Windows INI files:

[Setup1 Files]
[email protected],$(AppPath)\OrigJPGs,,,3/5/10 6:20:22 PM,5091,0.0.0.0
[email protected],$(AppPath)\OrigJPGs,,,3/5/10 6:19:31 PM,3143,0.0.0.0
[email protected],$(AppPath)\OrigJPGs,,,3/5/10 6:18:28 PM,2376,0.0.0.0
[email protected],$(AppPath)\OrigJPGs,,,3/5/10 6:17:26 PM,3273,0.0.0.0
[email protected],$(AppPath),,,3/5/10 6:22:11 PM,2660,0.0.0.0
[email protected],$(AppPath),,,3/5/10 8:49:47 PM,24576,1.0.0.0

This example packages five JPG files with the EXE. Four of them go into an OrigJPGs folder under $(AppPath) and one of them goes into $(AppPath) itself. When the package's setup1.exe runs, it will create \OrigJPGs under the target application folder and copy the first four JPG files there.

There is more on the use of the PDW in the VB6 documentation, and more details in several KB articles.


The PDW was slated for retirement even at the time VB6 was released. Microsoft was in the process of moving Windows from the older Setup API used by scripted installers (like PDW Setup packages) to the Windows Installer Service. Since the details were still being tinkered with to support new Windows installation features for Windows 2000 and Office 2000, VB6 went out the door with just the slightly updated PDW.

By late 1998 Microsoft had a first cut at a replacement for the PDW. It was called Visual Studio 6.0 Installer 1.0 (VSI 1.0) and made available as a free upgrade for VB/VS 6.0 Pro and Enterprise users. Once Windows 2000 and Office 2000 were ready to ship a few enhancements were made and VSI 1.1 was made available in late 1999 or early 2000.

VSI 1.1 was meant as a total replacement for both the PDW and for VSI 1.0, though it still lacks a few features in PDW. Most of those features are related to creation of IE ActiveX control packages. More sophisticated packagers were to be provided by 3rd party developers such as InstallSheild, Wise, etc. But VSI 1.1 was the last VB6 packager Microsoft ever provided.

Later versions of VSI were integrated more tightly with Visual Studio and only support VC++ and the .Net compilers.


Using VSI 1.1 it is possible to have a lot more control over things like folder and file deployment. Using VSI 1.1 you can create folders within a broader range of Special Folder locations than the out-of-box PDW supports, though you always have the option of creating modified versions of Setup1.exe that can handle additional "installation macros" for more Special Folders. Setup1 is writen in VB6 and the source is provided in the PDW folder.

VSI 1.1 can create empty folders on installation, which the PDW doesn't do.

Windows Installer traded text-based "scripts" for a database-driven model. The .MSI files consumed by Windows Installer are databases that contain the files to be installed along with instructions on how to install them.

Using tools from the Windows Installer SDK such as Orca.exe you can edit MSI databases to add features to your Installer package that VSI 1.1 doesn't directly support. One of these is the ability to set the security on folders and files, which is often necessary when data files are deployed to the proper folders under places like CSIDL_COMMON_APPDATA.

Many 3rd party packaging tools offer options for doing this without resorting to manually editing your MSI databases.


Sadly, you can't easily obtain VSI 1.1 anymore. In the past year Microsoft seems to have pulled it from their Downloads site.

[ThEiMp]

Thanks for the help, and I am going to rate your post!!

[ThEiMp]

What kind of code do I use to, make empty folders be added to the "Setup.lst" file???

[ThEiMp]

Also how do we, add files into sub folders, that the parent folder does exist???

[dilettante]

Subfolders are created under one of the base-directory macros. In this example under $(AppPath). The Setup1.exe run will create the folder, just as it does for the application folder itself.

As I wrote up above, I don't think you can add empty folders using PDW or by editing Setup.lst files. The Wizard itself doesn't seem to offer any way. However How to use Package and Deployment Wizard installation macros says:

\path

A hard coded path, for example, "c:\mydir". This is only available by modifying the Setup.lst file. Valid only for Setup1 Files.

I suspect that c:\mydir would be entered using a leading \, as in \c:\mydir but this could be wrong. I don't have an example.

[ThEiMp]

Thanks it is now working for me!!
Thanks again!!

[ThEiMp]

Thanks both of the posts that you had given to me, worked. I am using the harder one, because I can control what is happening to the software, that I had created using COM!!

[dilettante]

Glad to know you got what you needed. Deployment is a messy subject all by itself.

[ThEiMp]

Yes, I know. I never useto do it, myself. I got the assistants to do it for me...