Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
I will outline a little more exactly how healing works which will assist in unde
rstanding why to use the following feature / component structure.
For the following assume there is only one Feature called "COMPLETE" and a few c
omponents 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 fo
llowing manner. The MSI will enumerate what feature the entry point or in this c
ase 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. T
he 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 ch
eck 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 FILE
4.TXT is missing nothing will happen. FILE4.TXT is not a primary key therefore t
he MSI will not care if it does not exist.
Now a very important thing to note here is if there are any parent FEATURES wind
ows installer will then step into the parent FEATURE and being this process agai
n 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 c
onfigure current user settings for all users of a given workstation.
When using Wise Package Studio the default actions within Wise will create a COM
PONENT called "CurrentUser" this component will have all of the HKCU registry ke
ys inside it. If your using other applications such as InstallShield I expect yo
u could achieve the same results relatively easily.
Now assuming we followed default configuration of Wise all of our components wou
ld go into the "COMPLETE" FEATURE including the aforementioned "CurrentUser" COM
PONENT.
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 che
cking routines. This would eventually get to the "CurrentUser" COMPONENT and wou
ld find that the primary key for the "CurrentUser" COMPONENT would not exist. Th
is in turn would trigger a heal of the entire COMPLETE FEATURE. Now on a small a
pplication this may be acceptable however if you have a 600mb application reinst
alling the entire application for a new user would probably be extremely excessi
ve.
So to counter this effect with the help of some of the mentioned persons this id
ea was developed.
Create a new FEATURE STRUCTURE as follows:
FEATURE
"CurrentUser"
Move your "Complete" FEATURE to a child of the "CurrentUser" FEATURE. so you wil
l have the following.
CurrentUser
------------Complete
Whenever you have an application which contains HKCU components put the HKCU com
ponents 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 CO
MPLETE FEATURE is checked as per normal windows installer operation. In a good p
ackage this will not result in healing of the COMPLETE FEATURE as it should alre
ady be delivered during install time.
But what is good about this is that once the COMPLETE feature is finished its ch
ecking routine Windows Installer behaviour steps up to the parent FEATURE in thi
s 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 effe
ctively you are now only healing a tiny portion of your package not the entire a
pplication.
Your HKCU feature will only contain CurrentUser components or components which c
ontain registry entries which are destined for the HKCU registry hive.
The complete feature will contain the main application including all "program fi
les\%appname%" and HKLM entries. The reason for this is explained in the first C
urrent User healing guide.
Now to make full advantage of this method of healing often you are required to p
ut files into the users profile directories such as "c:\documents and settings\%
username%\application data" or similar folders such as "my documents" etc.
This is a way to allow you to heal this folder for each user, without requiring
to step outside of the msi to maintain the healing process. Therefore no need fo
r active setup or other methods, this is all fully self contained within the msi
.
To understand how this works its important to know how the duplicate file table
works within the msi. The duplicate file table is used to reduce the size of an
msi and increase performance by not replicating files inside the msi. For exampl
e if you have a file in your package in the following locations which is identic
al the default behavious of msi is to not add this file again.
i.e.
c:\program files\%appname%\folder1\file1.txt
c:\program files\%appname%\folder2\file1.txt
here we have 2 files with the same name and structure. Under normal conditions t
he msi would recognise this file is the same and it would make an entry in the d
uplicate file table. If we assume in the above example .\folder1\file1.txt was t
he first file to be placed into this msi it would then show in the file table as
a normal file as expected. However when we add .\folder2\file1.txt what you wou
ld expect is that another entry would be added to the file table as per the prev
ious entry. However if the msi recognises the file is identical it does not use
another entry in the file table instead it creates an entry in the duplicate fil
e table. The duplicate file table then makes a pointer back to the first locatio
n where this file was installed to.
Therefore .\folder1\file1.txt was the first entry so instead of .\folder2\file1.
txt being added again it uses the duplicate file table and makes a reference bac
k to the install directory of the first file1.txt. In this case "c:\program file
s\folder1\file1.txt". What this means is that .\folder2\file1.txt does not get i
nstalled from the cabs of the msi but installed directly from its first install
directory.
In other words the .\folder1\file1.txt is copied to .\folder2\file1.txt.
Hopefully that hasn't confused you too much :-).
The next step is to do this.
As with the first guide I wrote you create your feature structure with the HKCU
feature at the top of the tree. You then do this.
HKCU - (CurrentUser components)
-
- Complete Feature (remainder of app)
- Complete
- All other components
This means that HKCU is at the top of the tree and contains both the CurrentUser
components containing the HKCU registry entries. And the duplicate file table e
ntries are in the same component.
The complete feature just contains the main application.
Putting it all together.
When you run the application and a user has not logged on before the HKCU entrie
s are not present. Therefore when advertising is run from the complete feature t
he Complete feature is checked, all component keypaths are checked if something
is missing from the Complete feature it is healed in its entirety. As per normal
the MSI will then step up the tree and run the checking functionality as per be
fore. However in this instance as the advertising is downlevel from the HKCU fea
ture the healing process changes slightly and steps into what is classed as Comp
onent level healing. Therefore if a keypath is missing only the single component
is healed and not the entire feature. This is the reason why I like to put the
duplicate file info into the same component as the HKCU registry entries.
If you delete the HKCU entries when advertising is next run it will put back bot
h the HKCU entries and the files as they are in the same component as the HKCU k
eys.