I have a windows service exe that is compiled as x86, amd64, and Itanium. I’m trying to build a single x86 WiX/MSI installer that is used to install this service. The installer has three components with architecture specific conditions (e.g. <Condition>NOT VersionNT64</Condition> is used to detect x86), so only one of the components is ever installed on any given architecture. These components install either the x86, x64, or Itanium build of the exe.
This all works fine and the correct binary is installed on each of the three platforms.
The next step is to setup a Windows service for my exe using the ServiceInstall tag, and this is where we run into trouble: apparently the Name attribute of the ServiceInstall tag must be unique within the WiX file. I’d like to call the service e.g. FooBar on all three platforms, but this isn’t allowed – the WiX file fails to compile because of name collisions.
As a workaround I could have architecture dependent service names, e.g. FooBar_ia64, but this seems ugly to me, plus the code base has a number of places that makes assumptions about the service name, so if I change the service name, I will have to find and modify all these places in the code base.
I tried moving the ServiceInstall into its own Component that would be installed on all three architectures, but the ServiceInstall tag apparently implicitly references a File tag defined in the same Component so that didn’t work either.
I’m also aware that I could produce one installer per architecture and thereby avoid any conditionals in the installer and my problem would simply go away. But I really dislike the idea of having three installers when I’m so close to having a single installer for all three architectures 🙂
Any other tricks to get around this issue?
And just in case you didn’t figure this out yet, this is a legacy code base that I’ve inherited and I’m trying to build a new installer for it to replace the existing legacy installer.
This actually seems like a bug in WiX. When you do what you say it generates an error message about duplicate Primary Key but in reality the ServiceInstall table in the MSI SDK doesn’t say anything about the Name column being primary. Throught the user of mutually exclusive components you should be able to author multiple versions of a Service and not run afoul of any component rule violations.
The WiX team probably figure they’ll just be more conservative and prevent people from shooting themselves. The other thing they would probably say is don’t do hybrid installers in the first place but you already know that.
The best I can think of as a work around is to use a custom action at install time to author a temporary row into the ServiceInstall table to get around this compile time limitation.