I'm sure you know this but the custom action is in the MSI rather than the MSM and no it isn't created if the dummy directory is not present. I have attached my test samples if they are any use.
 
Incidentally, reading the documentation on this I spotted an interesting gotcha. If you were to use the value [WindowsFolder123] it still creates a custom action to convert [WindowsFolder.moduleguid] to [WindowsFolder]! As my colleague pointed out, all the more reason to ignore merge modules and use WiX fragments.
 
Thanks for your help on this.
 
Neil


From: Derek Cicerone [mailto:[EMAIL PROTECTED]
Sent: 11 August 2006 18:16
To: Neil Sleightholm; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Possible MergeModule bug

I agree – there should be some way to catch this mistake.  Before you added the dummy directory entry, did the MSI even include the custom action to set the modularized directory name to the real directory name or did it omit that?  Basically, I’m trying to figure out what crumbs will be left behind by the merge process that we might be able to catch in an ICE.

 

Thanks,

Derek

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Sleightholm
Sent: Friday, August 11, 2006 9:27 AM
To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Possible MergeModule bug

 

Yes adding the dummy entry fixed the problem. We have checked both VS2003 and VS2005 and neither of them create modularized folder names - so I guess that is where the bug is!

 

In an ideal world there should be an ICE error if the dummy folder is missing.

 

Neil

 

 


From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: 10 August 2006 18:01
To: Neil Sleightholm; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Possible MergeModule bug

Standard directories are a little bit different.  The way they work is you add a GUID to them everywhere.  You also need to make sure the WindowsFolder is listed in your Directory table for your Merge Module (which I think is probably the root of your bug).  Then, during the merge process mergemod.dll creates Type 51 CustomActions that resolve WindowsFolder.GUID to WindowsFolder.

 

I think this is silly.  My original draft of the Merge Module specification did exactly what you described below.  However, the final draft of the spec was updated as per above.  I never got a good answer (at least, not one I remember <wink/>) why the documented way is better.  I want to say it had something to do with the way UI in Merge Modules might work... but whatever.

 

Try adding WindowsFolder to your Directory tree.

 

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Sleightholm
Sent: Wednesday, August 09, 2006 12:28 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Possible MergeModule bug

 

I think we have found a bug in WiX (both 2 and 3) concerning the "modularization" of various field values when making a merge module. As we understand it "modularization" means appending the module GUID to things like component names to make them unique when actually merged into an MSI. The WiX code also does this for properties in formatted fields, presumably to avoid property name clashes with the "parent" MSI (or any other merge modules). It doesn't "modularize" if the property is a standard one, but this check fails to include standard directories (which can also be used as properties). We found this bug when attempting to set a registry value for an event source, e.g.:


<Registry Root="HKLM" Key="SYSTEM\CurrentControlSet\Services\Eventlog\Application\Enterprise Library Logging" Name="EventMessageFile" Value="[WindowsFolder]Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll" Type="string" />


In this example [WindowsFolder] ended up as [WindowsFolder.moduleguid]. This of course fails to resolve in the MSI resulting in an empty substitution value. We checked the same thing using a VS merge module setup project and it was fine. We traced through the WiX2 source and added the additional check for a standard directory in OutputRow.cs (on or near line 231) and it now works ok e.g.:

 

string identifier = group.Value;
if (!Common.IsStandardProperty(identifier) &&

    !Common.IsStandardDirectory(identifier) &&

    (null == ignoreModularizations || !ignoreModularizations.ShouldIgnoreModularization(identifier)))
{
    sb.Insert(group.Index + group.Length, '.');
    sb.Insert(group.Index + group.Length + 1, moduleGuid);
}

 

We think the call to "IsStandardProperty" ought to automatically call "IsStandardDirectory" but that may be a too "global" change.

 

Could someone confirm whether this is a bug and whether I should raise a bug report for it.

 

Regards

 

Neil

 

Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]

 

Attachment: Setup.wxs
Description: Setup.wxs

Attachment: Merge.wxs
Description: Merge.wxs

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to