Problems with CustomizeDlg and Installation directory
Michael Adkins
provided with the standard internal UI in the SDK. (I am
authoring with ORCA, and using Windows Installer 2 on
Windows XP.).
When you complete an installation, then go back into
Modify the installation, the CustomizeDlg screen has what
seems to be many strange behaviours to me. Can anyone help
with some work-arounds?
Firstly, the install directory tied to each of the listed
features does not update to the current installation
directory for that feature, but rather it uses the default
directory determined from the Directory table. This causes
all sorts of problems when you for example choose to
install to local disk a sub-feature that was originally
set to unavailable. If its parent was installed in a
directory other than the default, the subfeature ignores
any relevant path and simply installs in it's default
directory.
Example
========
MainApp
+- Doco
Defaults for MainApp might be set to Program Files\MainApp
and Doco to a subfolder called Doco to reside under
MainApp eg: Program Files\MainApp\Doco.
Lets say during the original install, Doco was set to
unavailable, and MainApp was set to C:\MainApp instead. If
you go back later and set Doco to Install to Local Hard
Drive then Doco gets installed at Program
Files\MainApp\Doco rather than C:\MainApp\Doco.
Secondly, in addition to the directory setting being
incorrect, it is actually displayed to the user on the
dialog when as far as I can see the settings should have
hidden the "Location" label that is tied to
the "SelectionPath" event. I understand that in
Maintenance Mode the SelectionPathOn event is not
published, so the "LocationLabel" and "Location" labels
will not be hidden or shown via this method, however there
is an entry in the ControlCondition table to hide these
labels as well as the Browse button when the "Installed"
property is True. The LocationLabel and Browse button stay
hidden, but it seems that the updating of the text in
the "Location" label (but the SelectionPath) event causes
the label to become visible again. Dodgy, but I'm not too
concerned about this as I'd like to show the user the
correct path anyway (assuming I can correct the problem
above) rather than hiding it.
Another problem seems to be that the "AbsentString" is
reported for a subfeature with customizable directory
instead of even the incorrect default directory. You can
get the incorrect default string to appear in the end, by
switching the state away from Install to Local Hard Drive
and then back again. Doesn't occur for the main feature,
this shows the incorrect default straight away.
A further discrepancy seems to be the browse button. The
SDK doco states that such a browse button should become
disabled whenever the selected feature in the
SelectionTree has a directory property that cannot be
changed for some reason (maybe some components are already
installed at this location). This doesn't work though as I
can remove the ControlCondition that hides the Browse
button and it is in no case disabled on the CustomizeDlg
when I am in Modify an Installation. If you use the
button, the UI indicates the directory changes but the
changes are ignored by the installer unless the directory
is not being used (the expected behaviour, but the button
isn't disabled in cases where the directory update will
not work).
It seems to me it should work like this:
If the feature is installed, it should pick up the current
installation directory. I should be able to show this to
the user on the "Location" label, but the Browse button
should be disabled as it obviously can't be changed if the
feature is already installed. But for a feature that is
currently unavailable, when a user selects to install it
locally, they should then have the option of changing an
*updated* default directory to determine where the
components of that feature are installed.
I don't know if the problems are with the way I have
things set up, or if they are known problems, but I would
appreciate any help in getting towards this functionality.
I've got a custom action to write out the install location
to the registry ARPINSTALLLOCATION, but am not sure how to
read it back in and in any case it only solves the problem
for the main target dir. A better solution would be
something dynamic per feature/component.
Michael Sanford [MVP]
outlook crashed. Sorry, but I'm keeping this one short and saving every other
word.
I think the majority of your problems are rooted in the fact that you have
something setting the default directory every time your msi runs. This should
only happen if the product is not installed.
Your expactation of what it should be doing are pretty close, with the exception
of being able to set a directory in maintenace mode. If the product is
installed, the Browse button should be hidden no matter what. Setting a
directory after the product is installed will cause havoc.
SelectionPathOn IS fired anytime a Feature is selected that is absent -- even in
maintenance mode. That's why the Text Control is being displayed.
HTH, and sorry my much more verbose replies were lost... ;-(
--
R. Michael Sanford
Windows Installer MVP
+++++++++++++++++++++++++++++++++++++++++++++++++++++
ActiveInstall Professional is now available!!!
- Visit http://www.activeinstall.com and download a trial today!!!
- Ask nicely and I'll even give you a special discount code! ;-)
+++++++++++++++++++++++++++++++++++++++++++++++++++++
"Michael Adkins" <mike_...@bigpond.com> wrote in message
news:020201c32c52$a1c09880$a301...@phx.gbl...
Michael Adkins
Hi Michael and thanks for your persistance in replying! :)
What you say about the default directory makes sense, but
I don't think I actually have something like that
occuring?? Can you point me towards what might be setting
my default directory. I haven't any custom actions
modifying these properties, all I have is the DefaultDir
field in the Directory table, but as far as I know it is
a required field and can't be conditionally set??
Also with respect to the SelectionPathOn event being
fired in Maintenance mode, I initally suspected this is
what was happening too, despite the SDK doco saying this
event wasn't published in Maintenance mode. But when I
looked closely, the "LocationLabel" (just a constant
string "Location:") also has its visible property tied to
this same event and it ISNT displayed in Maintenance
mode, which seems to suggest the event isn't occuring. I
concluded something else was redisplaying the label.
Maybe it is intended function when the text in a label
changes, I haven't tested it with another label to see.
Any comments appreciated....
Michael Sanford [MVP]
Can you send me a sample that reproduces this?
--
R. Michael Sanford
Windows Installer MVP
+++++++++++++++++++++++++++++++++++++++++++++++++++++
ActiveInstall Professional is now available!!!
- Visit http://www.activeinstall.com and download a trial today!!!
- Ask nicely and I'll even give you a special discount code! ;-)
+++++++++++++++++++++++++++++++++++++++++++++++++++++
"Michael Adkins" <mike_...@bigpond.com> wrote in message
news:088501c32cbd$f10789b0$a101...@phx.gbl...
Michael Adkins
Do you have orca? Funnily enough the Orca installation
itself actually demonstrates this problem (including a
few other bugs too). I have been comparing installations
that do and don't seem to have this problem and I have
traced it to the following:
If you have a directory specified against a feature (to
allow customisation of this directory), then this
directory MUST appear against one of the components that
belong to the feature or the following problems occur:
* The path string shows up on the CustomizeDlg, no matter
what settings you have to hide it.
* Any sub features that were not originally installed, or
that are removed and then re-installed through the GUI,
get installed at their designated folder under the
default base directory rather than the customised base
directory.
To see this, here is a simple MSI that shows the problem:
Michael, I will send it to your email privately, but for
anyone else following this thread, here are the tables
you need to author to see what I'm talking about (or just
email me and I'll send you the MSI :) ).
Use the UISample.msi that comes with ORCA as a base.
You need to add the standard properties (ProductName etc)
and customise the SummaryInformation tab. Set the
compressed source to off.
Now the tables: Note I changed the tabbing in these
fields to display nicely in a text editor, so you will
probably curse me if you are copying and pasting into
ORCA. :)
Component Table
===============
coReadme1 {172A7D5A-8447-4264-B229-875C3984283A}
SubDir1 0 Readme1.txt
coReadme2 {43FF3305-A492-4843-BA98-E8B9F83CA1CE}
SubDir2 0 Readme2.txt
coReadme {EF0559B8-B67E-437C-9023-61EF52B16C4C}
INSTALLDIR 0 Readme.txt
Directory Table
===============
TARGETDIR SourceDir
INSTALLDIR TARGETDIR BaseDir:.
SubDir1 INSTALLDIR Sub1:.
SubDir2 INSTALLDIR Sub2:.
Feature Table
=============
Sub2 Main Sub2 Sub2 3 3
32
Main Main Main 1 3 INSTALLDIR
48
FeatureComponents Table
=======================
Sub2 coReadme2
Main coReadme1
Main coReadme
File Table
==========
Readme2.txt coReadme2 Readme2.txt 1
1
Readme1.txt coReadme1 Readme1.txt 1
1
Readme.txt coReadme Readme.txt 1
1
Media Table
===========
1 999
Once you have it in and it Validates okay, you need to
create the three text files in the same folder as the MSI
file. (Doesn't matter what goes in them).
Now try the following:
These first steps show the CORRECT operation.
1. Run the installation and choose the Custom Installation
2. Change the the directory of the Main feature from
C;\BaseDir\ to something else, say c:\BaseDirFred\
3. Select NOT to install feature Sub2 (choose NOT
AVAILABLE).
4. Complete the install. Have a look at your harddrive,
things should be as you would expect.
5. Now run the install again and choose Modify. You
should see NO Path displayed when you select the Main
feature.
6. Now turn on feature Sub2 (select install to local
drive) and complete the install.
7. Look again at your harddrive and you should find that
a folder Sub2 has been created under c:\BaseDirFred\ (or
whatever you called it), just as you would expect.
8. uninstall the product.
Now to see the error:
9. Edit the MSI in ORCA and change the Directory of
component coReadme to be SubDir1 instead of INSTALLDIR.
Repeat the steps above and observe the following
differences:
* Step5: There will be a path displayed in the Modify
Installation dialog, for the Main component. This path
won't show the correct installation location however, it
will show the default c:\BaseDir\.
* Step7: When you add Feature Sub2, you will find that
the files haven't been installed where they should have
been (eg c:\BaseDirFred\Sub2), but have been placed in a
C:\BaseDir\Sub2 regardless of what you customised BaseDir
to be. (They are put in a location which is only correct
if you installed at the default path to begin with).
Michael Sanford [MVP]
You've done a great job of mucking through the problem to find the root cause.
It seems to me that validation should catch features with directories assigned
that are not also assigned to a member component and issue a warning at the very
least.
I have a mechanism available where I can get this escalated to the right folks
at MS so I'll give that a shot and see what happens. ;-)
Chris and/or Carolyn -- if you see this, perhaps you can comment? Am I correct
in thinking that it is an authoring problem that should be picked up by
validation?
--
R. Michael Sanford
Windows Installer MVP
+++++++++++++++++++++++++++++++++++++++++++++++++++++
ActiveInstall Professional is now available!!!
- Visit http://www.activeinstall.com and download a trial today!!!
- Ask nicely and I'll even give you a special discount code! ;-)
+++++++++++++++++++++++++++++++++++++++++++++++++++++
"Michael Adkins" <mike_...@bigpond.comxxxxxxxxxxxxxxxxxxx> wrote in message
news:087901c32f3a$7cc59cc0$a601...@phx.gbl...
Michael Adkins
right people, that'd be great. Thanks again for your
interest with it.
I guess it is an authoring problem, but the reason I
authored it this way to begin with is to achieve the
following, and perhaps you know of a better way or more
widely used approach.
If I have a development structure as follows on my hard
drive:
.....\My Progs\SomeApp\V1\00\Source\
.....\My Progs\SomeApp\V1\00\Output
.....\My Progs\SomeApp\V1\Doco
.....\My Progs\SomeApp\V1\Licencing
and so on, and I want to be able to reference files from
these directories in the installer database, so when I
run the filer script WiMakCab script etc, it picks them
all up and crams them into the MSI. I didn't want to have
to copy individual files to a separate staging area with
a flat file structure before doing this as I'm worried
I'll forget to copy a file and it won't be picked up when
I rebuild the package to a later version.
So I put my MSI at the
.....\My Progs\SomeApp\V1
level and built a directory table something like this:
INSTALLDIR ProgramFilesFolder SomeApp:.
ProgramFilesFolder TARGETDIR PFILES|Program
Files:.
SystemFolder INSTALLDIR .:Files
LicenseDir INSTALLDIR .:License
CompilerOutputDir CurrentReleaseDir .:Output
CurrentReleaseDir INSTALLDIR .:01
ReleaseDocoDir CurrentReleaseDir .:.
TARGETDIR SourceDir
OtherFilesDir INSTALLDIR .:Files
ProgramMenuFolder TARGETDIR PROGRAMS|Programs
UserDocoDir INSTALLDIR .:UserDocs
It looks really untidy (I hope it formats a bit better on
your screen), Its pretty ugly anyway and not too easy to
maintain, but it essentially maps my faily deep
development folders into a pretty flat final structure.
The difficulty is I then have to reference for example
CompilerOutputDir against my MainApp component, rather
than INSTALLDIR. And this causes the problem described in
the previous posts where it is possible for none of the
components in my feature to actually be specified as
having INSTALLDIR (because they all are specified with a
subfolder of this). I hoped I could allow the user to
customise this folder and the relative paths would just
update, but....
Is there an easier way? All I realy want is for my actual
build files, user doco files etc to be used rather than
having to copy them, because of the risk of them getting
out of sync....
But after the last few days, I'm thinking it'd be just
less hassle to write a script or batch file... :) How
does everyone else do it??
Michael Sanford [MVP]
mentioned. It's a bit more work upfront, but will make it easier in the long
run.
Of course you could always look at a commercial tool to take care of all of that
for you... ;-)
--
R. Michael Sanford
Windows Installer MVP
+++++++++++++++++++++++++++++++++++++++++++++++++++++
ActiveInstall Professional 2.0 -- Windows Installer Made Simple!
Visit http://www.activeinstall.com and download a trial today!!!
+++++++++++++++++++++++++++++++++++++++++++++++++++++
"Michael Adkins" <mike_...@bigpond.comxxxxxxxxxxxx> wrote in message
news:011201c33046$c3d9f130$a501...@phx.gbl...