I've noticed that InstallShield sometimes uses it's own Custom Actions for what you might think are fairly simple operations. The best bet would be to create a basic MSI from InstallShield, decompile it, and see what the resulting wxs looks like.
On Sat, Jun 20, 2009 at 2:55 AM, JW<improvi...@yahoo.com> wrote: > Some legacy components of our application require an environment variable > that we are setting with the Environment element. This is the WiX code: > <Environment Id="SetHome" Action="set" Name="APPHOME" > Value="[INSTALLLOCATION]" System="yes" />. On Windows 2003 it is not > propagated to Command Prompt windows that are opened in the same session. > (This happens with both 3.0.4805 and 3.0.5271.) The variable shows up the > control panel (and the registry), so it has been set properly. The kicker is > that with the old InstallShield installer, the variable IS propagated to the > child windows. Does anyone have any insights or suggestions? What is > InstallShield doing that MSI isn't? We really don't want to have to prompt > the user to reboot. I tried adding a custom action that broadcasts a > WM_SETTINGCHANGE message, but I assume the installer does that already. > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
