Generating MSI installers for windows services with configurable service names with MSBuild

Greetings, I'm trying to figure out how to pull off the following scenario with MSBuild and Visual Studio 2010.

1. I have a set of three servi开发者_如何转开发ces that I would like to install. The default installation directory should vary with the build (qa, uat, and production).
2. To add another fun wrinkle to this whole thing, sometimes the uat environment can be pressed into service when we are at peak load, so each build of the service will need to have a different name. It doesn't happen frequently, but it is on the list. How can I configure the service installers to alter the service name dynamically?
3. I want to be able to create MSI installers for the services (for whatever the current build is). I have an existing and extensive MSBuild script for the various websites I'm working with already, but I'm a little unsure how to proceed with making the services work.
4. Obviously, the configuration files for each service build will be different.
5. I've added installer classes for each of the services.

I guess I'm a little confused with how to start this, so any help I can get would be awesome. I had considered simply hardcoding the different service names and using conditional compilation statements to set them, but I don't think doing so is a particularly clear way to go about it all. Any thoughts?

It might be simpler to just zip up the service bits during the build and deploy with MSBuild using or MSBuild Extension tasks. You would put your environment specific configuration data in an msbuild .properties file (mylocal.service.properites, qp.service.properties, uat.service.properties, etc.). This is the way I deploy services.

note: the property file would contain things like your db connection string, TargetDir, ServiceName, etc.

Service names are specified at install time see 'sc', 'installutil' or the WindowsService msbuild extensions pack task snippet below. This means you can copy the same service bits everal directories and install each with a unique name (e.g. QAService, UATService, PRODService).

note: I want to reinforce that the service name is a deploy-time consideration, not a build-time consideration.

<WindowsService TaskAction="Install"
                ServiceName="$(ServiceName)"
                MachineName="$(TargetServer)"
                ServicePath="$(FullServicePath)" 
                User="$(User)" />

The approach is similar for MSI installers. I assume your installers prompt for all necessary environment specific configuration data... All [decent] installers have a way to provide answers from a file versus using the installer interactively. So, as above, you create one answer file per environment and feed it to the installer on the command-line.

You do not want to do this at build time... and thereby have a separate installer per platform. Was forced to do this with an ancient version of the wyse installer. Made me sad. You want a single MSI installer that can be run in every environment (given the environment specific answer file).

Details of the MSI command-line and answer file format will vary by product. What installer package are you using?

Cheers, /jhd