I have created a setup project for a Windows Service that was written in .NET. The Service depends on several elements in the App.config that is different in the dev environment from production environment (ex: path to a folder)
I now have the MSI file that I can run in production to install the service. However, how do I change the value of config elements?
I am not sure what the best practice is.
I haven't used WiX in a while but it is a really great toolset for creating installers. It has a lot more functionality than Visual Studio's built in msi functionality. In particular it has support for exactly what you are asking about here, I recommend moving your installer over to WiX and use that xmlconfig functionality.
There is no magic code to do it, no designer help.
What I did is create a .net installer class and use that to get access to the installed services app.config:
ConfigurationManager.OpenExeConfiguration(Context.Parameters["assemblypath"]);
You can then use configuration manager to make your changes and save them back in. If required you can design a dialog and run it from the installer in your custom action.
Have fun though, MSI is EVIL. Word of advice is to COMPLETELY disregard any of the options about uninstallpreviousversions, detectifnewer etc. They do not work the way you expect and upgrading your service will cause you severe pain. I am currently experiencing this now and our solution has 12 services to manage...
Hi there. Spence is right about MSI format being evil. Got myself some angry customers when they couldn't uninstall my service :)) Take a look at http://installer.codeeffects.com. I used them to build an installer of one of my services. Everything looks ok in testing so far. I plan to move to exe format completely if my customers will have no issues with this exe installer in a month or so.
This is not a best practice, but rather what I do, in case you may find it interesting.
I make copies of the App.config, let's say App.config.debug and App.config.production, and I just open App.config and the appropriate other file and then copy/paste into the App.config as needed. Yes, it's not ideal and it would certainly suck if you had more than one production deployment target, but I haven't found anything I liked more. If you're using source control you might choose to leave the App.config out of it, since with my convention it is just a copy of one of the other files.