john

I have scrawled up some posts and was asked by one of your
groupies if I could post some of them in here.

So this is just for comments from anyone whom is
interested. I have plenty more this is more so to get
feedback from you guys.

Current User self healing.


First I will outline a few important items which are
critical to building MSI packages.


Features: A feature is a container which may hold
other features and components.

Component: A component is a container designed to
hold application related information such as:
regsitry keys
files
ODBC configuration
to name a few. A component has a unique
identifier called a {GUID} which is represent by a 16 bit
HEX code.

Primary Key: The primary key is an item in a component
which is checked during advertised actuation.

Entry Points: Items within the package can be
advertised. It is common to use shortcuts and file
extensions as advertised entry points. An
advertised entry point will trigger the checking of
primary keys for components within a
feature.


I will outline a little more exactly how healing works
which will assist in understanding why to use the
following feature / component structure.

For the following assume there is only one Feature
called "COMPLETE" and a few components such
as "COMPONENT1" "COMPONENT2" and "COMPONENT3"

COMPONENT1 contains 1 file "FILE1.TXT" with a primary key
of "FILE1.TXT"

COMPONENT2 contains 1 file "FILE2.TXT" with a primary key
of "FILE2.TXT"

COMPONENT3 contains 1 advertised shortcut "SHORTCUT1"
contains 1 file "FILE3.TXT with a primary key
of "FILE3.TXT"
contains 1 file "FILE4.TXT

COMPONENT4 contains 1 HKCU reg key with a primary key
of "HKCU\test"

When an entry point such as a shortcut is triggered in an
MSI the following will occur. The msi self healing
operation will begin its checking process in the following
manner. The MSI will enumerate what feature the entry
point or in this case the shortcut belongs to. For the
above example assume a user runs SHORTCUT1 which is the
advertised entry point. This action will cause the MSI to
find out what FEATURE SHORTCUT1 is in. The next step is to
find out what other components are in this feature. In
this case COMPONENT1 COMPONENT2 and COMPONENT3

Each of the COMPONENTS in the same feature as the entry
point will be checked. The primary key of each component
will then be checked against the workstation to ensure
that these primary keys exist.

In this case COMPONENT1 has a primary key of FILE1.TXT
therefore the msi will check if FILE1.TXT exists on the
workstation and continue this process through all of the
COMPONENTS within the same FEATURE the entry point is in.
If any of the PRIMARY KEYS are missing the entire feature
is healed. As depicted above if FILE4.TXT is missing
nothing will happen. FILE4.TXT is not a primary key
therefore the MSI will not care if it does not exist.

Now a very important thing to note here is if there are
any parent FEATURES windows installer will then step into
the parent FEATURE and being this process again and
continue until all parent FEATURES are checked.

Now for the interesting part.

Anyone whom has been packaging for a while will know that
HKCU registry keys are often the cause of trouble within a
package. The current user keys normally are only delivered
the user whom is logged in at the time of installation.
The msi technology has attempted to overcome this
shortcoming and uses self healing to configure current
user settings for all users of a given workstation.

When using Wise Package Studio the default actions within
Wise will create a COMPONENT called "CurrentUser" this
component will have all of the HKCU registry keys inside
it. If your using other applications such as InstallShield
I expect you could achieve the same results relatively
easily.

Now assuming we followed default configuration of Wise all
of our components would go into the "COMPLETE" FEATURE
including the aforementioned "CurrentUser" COMPONENT.

If you were to use this default methodology any new users
logging into a machine and running an advertised entry
point would trigger the healing mechanism's checking
routines. This would eventually get to the "CurrentUser"
COMPONENT and would find that the primary key for
the "CurrentUser" COMPONENT would not exist. This in turn
would trigger a heal of the entire COMPLETE FEATURE. Now
on a small application this may be acceptable however if
you have a 600mb application reinstalling the entire
application for a new user would probably be extremely
excessive.

So to counter this effect with the help of some of the
mentioned persons this idea was developed.

Create a new FEATURE STRUCTURE as follows:


FEATURE

"CurrentUser"

Move your "Complete" FEATURE to a child of
the "CurrentUser" FEATURE. so you will have the following.

CurrentUser

------------Complete

Whenever you have an application which contains HKCU
components put the HKCU components into a COMPONENT
called "CurrentUser" and put that COMPONENT into
your "CurrentUser" FEATURE.

The remainderof the application would go into your
COMPLETE FEATURE as pictured below.


Feature:CurrentUser

Component: CurrentUser

--------Feature:Complete

-------- Component: Component1
-------- Component: Component2
-------- Component: Component3

Now in this scenario if you run the SHORTCUT1 as per the
previous example the COMPLETE FEATURE is checked as per
normal windows installer operation. In a good package this
will not result in healing of the COMPLETE FEATURE as it
should already be delivered during install time.

But what is good about this is that once the COMPLETE
feature is finished its checking routine Windows Installer
behaviour steps up to the parent FEATURE in this
case "CurrentUser" and checks that feature also.

If a new user is logged in the primary key for
the "CurrentUser" COMPONENT will not exist which will
trigger healing on the "CurrentUser" FEATURE therefore
effectively you are now only healing a tiny portion of
your package not the entire application.

I hope this is helpful to some of you. Its pretty hard to
put into words so hopefully it will clear up some
behaviour and assist with healing HKCU components.

Next time I will address the Current User files.

Please if you have any comments feel free to mail me on
huckey@mindless.com

john

BRD thanks for you info I will run through some testing to
prove this.

Here's another little tidbit which i found and have not
yet tested.

"Apparently" if you have a keypath which is a registry
component again it can do a component level heal. This was
something i found in the SDK so I gather its correct just
hadnt the time to test it yet.

I have some other thoughts on healing files to the current
user also.

I will get it down in something legible and see what you
think.

John

brd

John,

First, I'll respond to two points you made about my comments:


If you are getting a request for source with Windows Installer 2.0 it must be
reinstalling a file. I would recommend checking the log file produced by the
self-repair. You can have logs generated during self-repairs by setting the
Logging policy. You should find that some file is being repaired and this is
causing the request for source. Even if you have a CurrentUser component with
just HKCU keys in a CurrentUser feature at the top of your feature structure,
every time a self-repair occurs the feature containing the advertised entry
point has a feature-level repair performed. If any files in this feature need
to be put down again the source MSI will be required. This request for source
does not always happen because often times these files will not be scheduled
for reinstallation due to Windows Installer File versioning rules as Dennis
stated. Usually, most versioned files and non-versioned files using the
MsiFileHash table will not need to be reinstalled and the request for source
can be avoided. To help this process try to keep your advertised entry points
in their own features and keep those features as small as possible.

One interesting point on logging that I recently discovered is that Windows
Installer 2.0.2600.0 produces a much more detailed log on self-repairs than
2.0.2600.1106 (the version numbers are from msiexec.exe). I did some testing
on both Windows 2000 SP3 (msiexec.exe 2.0.2600.0) and Windows XP SP1
(msiexec.exe 2.0.2600.1106). In both cases I set the Logging policy to
"voicewarmup". My log on WinXP SP1 was much less detailed and did not provide
the installed, request or action states for components and features. It also
seemed to be missing other information that I was able to obtain with the log
from Windows 2000.


When you say that the CurrentUser component is left in the same feature, if you
mean the same feature as your advertised entry point than this is still aligned
with what I have stated. The feature containing the advertised entry point
triggering the repair always performs a feature-level repair if ANY component
keypath in the MSI is broken. Therefore, if you place the CurrentUser
component in the same feature as your advertised entry point that keypath will
be broken and the entire feature will be self-repaired. If you place the
CurrentUser component in a feature somewhere in the feature structure above the
feature containing your advertised entry point then a component-level repair
will be performed on CurrentUser, reducing the chance of requiring source. You
can confirm this by running a log of a self-repair on a Windows 2000 (MSI
2.0.2600.0) system. Check the installed, request and action states of the
features and components - this will verify what I have said.


You other comment about using duplicate files within the same "CurrentUser"
component containing your HKCU keys seems to work really well - I just tested
it out. As for "why it works", it is because the DuplicateFiles action uses
the original files installed location as the source, not the actual source MSI.
At least this seems to be the behavior because it works fine if the original
file is present. If you remove the original file and self-repair it will fail
with a 1308 error.

This also works much better for installing files under a user's profile. If
you use the File table for this purpose and set one of these files as the
keypath it will register the keypath to a hardcoded location, which includes
that user's username. This causes problems when the MSI needs to repair for
another user. I have worked around this issue in the past by including a HKCU
key in these components and setting the HKCU key as the keypath. This gives me
another alternative for installing per-user files. Like the old method I used,
this new method using DuplicateFiles in your "CurrentUser" component probably
causes some ICE errors. Then again, if you look at your MSI the wrong way you
get about half a dozen ICE errors. :^)

Hope I was able to clarify some of my thoughts.

-BRD