Help with Windows Installer

On Sep 26, 7:53*am, Georgi <bill.hicks....@gmail.com> wrote:
> Hello,
>
> I need to make the installation for a product. I've decided on Basic
> MSI and basically have three problems.
>
> 1. I have a folder with a bunch of html files with some accompanying
> gif/jpg files. The problem is that when I put them in the files view I
> get more than a 1000 components. Apart from the obvious problem of
> having > 1000 components I also get some considerable delay in the ide
> I'm using (InstallShield 2010). Any ideas how to deploy this large
> quantity of files?
>
> 2. I have a database file that is ~7GB large and does not fit
> the cab file 2Gb limit. What would be the
> proper way of deploying such a large file?
> Up until now I've been using a custom action for decompressing an
> archive, but it comes with a different set of problems to deal with so
> I'm looking for a something more "native" to Windows installer.
>
> 3. I can't quite get my head around the following part of the
> component code rules :
>

-Change the name or target location of any resource that may be
> installed under the same name and target location by another
> component.
> -Otherwise guarantee that the new component is never installed into
> the same folder as another component which has a resource under a
> common name and location. This includes localized versions of files
> with the same file name. For more information, see What happens if the
> component rules are broken?.

> The first rule seems completely unpractical for me - i just can't
> change filenames or folder names everytime I need to update a file in
> a component - it would require a change in the application using
> them.
> The second part seems to be applicable to me, but I'm not exactly sure
> how to guarantee that the old version is uninstalled before installing
> the new component. What would be the proper procedure to accomplish
> this?
>
> Thanks!

1. For this first issue, there are a few solutions.
a. Is the target directory for each of the 1000+ files the same?
b. Do all the files meet the component rules that they can be in a
single component?
For each file that meets the condition of a and b above you should
be creating your own component in the component view and then adding
files through the component view. Or if you are comfortable with
InstallShield's automation interface you can add them using script
code. This will go a long way to simplify maintenance on your
project.

2. Is there any way that the database can be created programmatically
at install time or does it need to be installed already created? If it
is this large, I would leave it detached as an external Disk1 file and
have a custom action attach the database at the appropriate time in
your installation process. Don't add it as a support file, you really
don't want your users waiting for setup to copy 7GB of data to the
temp directory at the start of setup. You can copy the database to the
appropriate location during the installation process. But you are
right, there is a 2GB limit on CAB files. It would be much better if
the DB could be programmatically created and populated with data
through code rather than passing in an already created DB. But I
understand your situation. I have been there and done that too.

3. Component rules for upgrades are indeed confusing. Basically this
is saying you cannot move a file from your original install to another
directory if that file is shared by another component. This would
require a major upgrade instead of a patch/ minor upgrade. Remember
the qualifier is that the component is shared with another component,
so that they are interdependent on each other. So files in Component B
are expecting that files in Component A to be in directory A, but if
you move your file to Directory C or rename your file in Component A
to another name then Component B will not necessarily know about that
change. Also realize that components can be shared across products
too. This may not be true in your case, but in the world of Windows
Installer the possibility exists to allow component sharing between
products.
3b. The second part of this is for instances where you have different
versions of files for things like help in different languages. Often
all of these files are named the same, but they should be installed to
different folders, such as help/en, help/jp, help/es, help/de, etc.
This way files that are named the same are not overwriting each other
on upgrades.

Hopefully this helps.