For what little it's worth, InstallShield 11 did not support for Vista, much less the version of IIS included with Vista, because its predates Vista. If that's the only blocking factor, you may want to consider a version of InstallShield that shipped after 2005. If the other factors are more relevant to you, carry on.
Michael On Mon, Jan 3, 2011 at 19:45, InvaderZim <uwe.baem...@microfocus.com> wrote: > > > Christopher Painter wrote: >> >> InstallShield's custom action sets a property but there's no reason you >> have to use that property. You can write your own custom action setting >> your own property then tell the IIS custom actions to use that property >> instead. >> >> All said and done, InstallShield 2011 *currently* trumps WiX in IIS >> support IMO. This may balance out once WiX 3.5 ships. >> >> BTW, I think I recall this registry value you mention can't be trusted. >> It's set one time during the installation of IIS and doesn't always >> reflect the current document directory for the default root website. The >> only authoratative way I know is to call into IIS's API and ask it what >> the document directory is. >> >> BTW, I wouldn't write a custom action to "fix" it since it's not your >> registry resource that you are messing with. >> >> Christopher Painter, Author of Deployment Engineering Blog >> Have a hot tip, know a secret or read a really good thread that deserves >> attention? E-Mail Me >> > The InstallShield custom action I was describing creates IIS virtual > directories and applications. This uses some proprietary InstallShield DLL > that crashed if the PathWWWRoot registry entry contained an environment > reference (specifically, %SystemDrive%) because the environment variable was > REG_SZ instead of REG_EXPAND_SZ (Microsoft's mistake, not InstallShield). > We saw this failure in the MSI logs and I.S. was definitely reading this > variable, so I assumed that, if it's good enough for InstallShield, it's > good enough for us. > > Manually editing the registry and replacing %SystemDrive% with C: in the > registry value prevented the InstallShield custom action from cratering the > install. So we did that in a wrapper that was invoked at the start of the > install, and restored the registry variable from a cached location at the > end of the install. We sent a test case to InstallShield and they reproduced > the problem but said it wouldn't be fixed until a future version was > released. > > Unless the WiX IIS tooling doesn't use this variable, I'd imagine that this > will also be a problem for the WiX custom action unless it calls > ExpandEnvironmentStrings() on the value. If that's the case, I hope it gets > tested on each Windows platform. :-) > > Anyway, after that InstallShield frustration, we developed our own IIS > registration tooling in C# but it's not invoked via custom actions until the > install is complete and all the files are present. I currently need a > property that is set earlier and allows us to install the HTML and ISAPI > files into the web tree. We do not want to install them into C:\Program > Files because that directory is sacrosanct and our customers will want to > modify these web files. Putting the files into something like c:\Program > Files\Common Files or "All Users" is doable but it's easier to explain if > the files are dropped into the WWW tree and that also avoids permission > issues. > > I do think you're right about the PathWWWRoot variable -- if the "Default > Web Site" is moved, the PathWWWRoot registry entry might not track it. So > I'll have to bite the bullet and code yet another a custom action that > queries the IIS metabase directly and sets the property. > > I did spend some time over the last week experimenting with the WiX 3.5 IIS > configuration feature. It looks promising but I could NOT figure out how to > get it to set an MSI property that indicated where a physical directory for > a WebDirectoryor VirtualWebDirectorywas located. So I backed out those > changes. But if someone has figured this out, please share! > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Creating-Virtual-Directories-in-c-inetpub-wwwroot-in-WiX-tp688976p5887358.html > Sent from the wix-users mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
