Override values in app.config from installer msi

  • Thread starter Thread starter Onno
  • Start date Start date
O

Onno

Hi,

I've got a WinForm application (used within our company only) with a
list of constants, paths etc in app.config. A few of these constants
point to paths on our central server which is used as update server
(used to check for updates of the app itself and for several of the
things it used). For this app I've made an installer with Visual
Studio 2005.

Now the paths are fine for 95% of the users, but there is a single
department that want to use their own update server. So a few of the
constants need to be changeable. I do not want to make then really
configurable in the GUI of my app (other users will start to mess with
them) and I do not want build 2 versions of the app or create 2
installers. But I do need some way to let the department specify their
server.

What I thought of is this:
- Prior to running the Installer.msi, that one department double-
clicks a registry file they made themselves (I provide the template).
This registry file enters a path to a custom xml file with values to a
key.
- I move the settings to some 'OverridableSettings' class. Instead of
using AppSettings("ServerPath"), I will use properties from this class
for all fields that need to be overridable. Initially the properties
are set to the values from the App.Config file.
- But if the registry key is present, and the path is valid, the class
loads the values that are in the file.

Now, this will work but I don't have a good feeling about it. Anyone a
better idea? Is it possible to pass parameters to the msi created with
VS2005 and then let the installer pick another app.config or
something? Anything possible with the extended System.Configuration
namespace? (I didn't find anything suitable, but it's quite
overwhelming compared to .NET 1.1 in which I started with the
app.config file)

Many thanks,
Onno
 
Hi,

I've got a WinForm application (used within our company only) with a
list of constants, paths etc in app.config. A few of these constants
point to paths on our central server which is used as update server
(used to check for updates of the app itself and for several of the
things it used). For this app I've made an installer with Visual
Studio 2005.

Now the paths are fine for 95% of the users, but there is a single
department that want to use their own update server. So a few of the
constants need to be changeable. I do not want to make then really
configurable in the GUI of my app (other users will start to mess with
them) and I do not want build 2 versions of the app or create 2
installers. But I do need some way to let the department specify their
server.

What I thought of is this:
- Prior to running the Installer.msi, that one department double-
clicks a registry file they made themselves (I provide the template).
This registry file enters a path to a custom xml file with values to a
key.
- I move the settings to some 'OverridableSettings' class. Instead of
using AppSettings("ServerPath"), I will use properties from this class
for all fields that need to be overridable. Initially the properties
are set to the values from the App.Config file.
- But if the registry key is present, and the path is valid, the class
loads the values that are in the file.

Now, this will work but I don't have a good feeling about it. Anyone a
better idea? Is it possible to pass parameters to the msi created with
VS2005 and then let the installer pick another app.config or
something? Anything possible with the extended System.Configuration
namespace? (I didn't find anything suitable, but it's quite
overwhelming compared to .NET 1.1 in which I started with the
app.config file)
Click to expand...
Not knowing all the niggling details I would consider putting all the
department-customizable settings into their own XML document. When the
installer is run let the standard install point to a file containing
the default settings. If the user selects a custom install let the
user browse and select the custom XML file. All the 'universal'
settings could remain in the app.config.

regards
A.G.
 
When the
installer is run let the standard install point to a file containing
the default settings. If the user selects a custom install let the
user browse and select the custom XML file. All the 'universal'
settings could remain in the app.config.

regards
A.G.
Click to expand...
Thanks, but is that possible with the standard VS2005 installer?
(can't try right now, but I thought you could not do actions like
letting a user browse for files, etc).

Regards,
Onno
 
Thanks, but is that possible with the standard VS2005 installer?
(can't try right now, but I thought you could not do actions like
letting a user browse for files, etc).
Click to expand...
It should be possible using a custom action.

regards
A.G.
 
Thanks A.G.!

In the end, I did this:
- I moved all settings that must be changeble to a settings class.
This reads them from an XML file at app startup.
- The installer has a custom action (executed in an Installer class
from my app). This checks if there is a copy of the
XML file in the same dir as the msi of the installer. If so, the
custom action replaces the installed XML file with
the custom copy.
- So on our normal server, the XML file that is in my project is used
because there are no XML files in the release
dirs on our server. The 'special department' can put their changed
XML file in the release dir on their server.
- User sees nothing (no custom install or something). Clean and pretty
me thinks.

I only needed to pass the install and msi path to the installer class.
I found a little trick how to do that
here: http://www.xtremedotnettalk.com/showthread.php?t=77944. You can
do the same for the [SourceDir]
field which is the msi path.

Thanks for your help!
Onno
 
Back
Top