I'll do my best
Ok, I downloaded the file to take a look at the package. The 6.2 package has
similar problems. As it is currently authored, it won't be advertiseable since
it won't create an advertise script. First, it's missing an AdvtExecuteSequence
table. That needs to be imported into the package using a tool like Orca (or
perhaps one of the scripts in the Windows Installer SDK -- there's a sample
sequence package included as well which would have an AdvtExecuteSequence table
to go by).
Same problem exists for the MsgrFeat as well. It's currently authored with an
attribute value of 24 which includes msidbFeatureAttributesDisallowAdvertise. It
needs to be changed to 16 as well.
This is the same as the 6.1 package. I haven't had a chance to test the actual
deployment (I'm at home without access to one of my test machines) so I'm going
by some simulation code that I wrote based upon what I know about how
application deployment works.
With the above changes, I'm able to get an advertise script that is created
(whereas before it was a 0-byte file). However, I did notice that it didn't
contain any shortcut creation operations. (HINT: If you know the location of the
..aas file, you can use the wilstscr.vbs script provided in the Windows Installer
SDK to read the script file. You can find the location of the .aas file using
RSOP.) What this means is you won't see a shortcut for messenger when you deploy
it (most likely this is what you were looking for).
If it's the shortcut that is the problem, it's because of the authoring of the
Shortcut table. The Installer will only advertise shortcuts during application
deployment that fall in a shell folder path. Note that my observation of the 6.1
messenger package shows this to be true as well and that it suffers from the
same problem.
If you look at the authoring of the shortcut table, you'll notice that the
directory is ProgramMenuFolder.ADEB440D_7847_4F65_80BD_899870ED2EC9. While
ProgramMenuFolder is a shell folder, the syntax
ProgramMenuFolder.ADEB440D_7847_4F65_80BD_899870ED2EC9 actually illustrates a
merge module convention for shell folders to prevent conflicts. The way
directories work with MSMs, there's a type 51 custom action that sets the
directory to the appropriate shell folder value. When we added the
AdvtExecuteSequence table, we didn't add this custom action to it. Thus, the
directory isn't updated. The default evaluation for the folder property is the
root drive (in my case it's c:\) which of course is not a subfolder of a shell
folder.
You could either change the
ProgramMenuFolder.ADEB440D_7847_4F65_80BD_899870ED2EC9 reference to
ProgramMenuFolder in the Directory column of the Shortcut table or you could add
the type 51 custom action to the AdvtExecuteSequence table. So, in the
AdvtExecuteSequence table, I would add the row:
Action = ProgramMenuFolder.ADEB440D_7847_4F65_80BD_899870ED2EC9
Condition = {NULL}
Sequence = 1
or some other sequence number such that the action is sequenced BEFORE the
CostInitialize action. If this doesn't work for you, perhaps you could elaborate
on what's not correct in your deployment scenario?
Hope this helps,
- Carolyn Napier
Microsoft Windows Installer Team
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
MSI FAQ:
<
http://www.microsoft.com/windows2000/community/centers/management/msi_faq.mspx>
sebastian said:
This doesn't work for MSN Messenger 6.2 for windows 2000
Any chance, that you have a solution for this?
