As discussed in the last post, you can run both 32-bit and 64-bit app pools side-by-side on Windows Server 2008. I decided I didn’t want to have to remember to change the settings on one of my app pools every time I install my application on x64, so I added a custom action to the installer to do it for me.
Assuming you have already added the correct elements to create your application pool, all you need to do is add a custom action, like so:
1: <InstallExecuteSequence>
2: <RemoveExistingProducts After="InstallFinalize" />
3: <Custom Action="ConfigureAppPools" After="InstallFinalize"><![CDATA[NOT Installed AND VersionNT64 >= 600]]></Custom>
4: </InstallExecuteSequence>
5: <!-- SNIP -->
6:
7: <CustomAction Id="ConfigureAppPools" Return="check" Directory="TARGETDIR" ExeCommand="[SystemFolder]inetsrv\appcmd set apppool /apppool.name:"Your App Pool Name" /enable32BitAppOnWin64:true" />
The magic is performed by appcmd.exe. You just tell it the name (not the WiX ID!) of your app pool, the property you want to set, and the value, and it does the rest. Sadly this only works on IIS 7/Windows Server 2008, but the technique can be used to do all kinds of crazy things to your IIS configuration. Check out the documentation for appcmd.exe to see what other wonderful things you can come up with.
nice posts, i noticed this in your post which you may need to look at
<RemoveExistingProducts After="InstallFinalize" />
this is happening late in the sequences which is the default setting. however as WiX doesnt have any method that I am aware of to handle conflict management this would not work. You should schedule the RemoveExistingProducts action earlier in the sequences to ensure that your installation is not broken during an upgrade process. (assuming you have an absence of conflict management which I am pretty certain you do)
my blog defines more about these actions should you be interested.
@john,
Thanks for the heads-up, I’ll check that out.