Tuesday, May 02, 2006 3:23 AM
I have a VS 2005 Win Forms Application that is being developed for a client.
Once system tested, I want to hand over the application to the client with some instructions for installation and setup in their environment, i.e. they need to specify connection strings, web service url's, timeout periods, etc in the app.config. There are many settings here that they could potentially change (10-15).
However, when I use click-once to publish the application, how does my client change the settings within the app.config?
It seems to me that once published, these values are locked.. even if I change them in the app.config before installation on a PC, the old values are still used.
Can someone please provide some explanation around deployment for this scenario?
Is Click-Once the best approach.. should i be using an install project (if so, how does the client change the settings here given its inside an .msi)?
Should I have stored my configurable settings somewhere else? I thought the Application Settings function within Visual Studio 2005 was meant for this?
Tuesday, May 02, 2006 6:58 PM
I'm new to all of this myself. But, while looking for an answer tio my own stuff, I stumbled across this.
I didn't read the whole article, but this sounds like it's in the ballpark of what you are looking for.
Hope this helps.
Tuesday, May 02, 2006 11:21 PM
Thanks Jonathan. I will keep this in mind, but unfortunately I've already written my app using the VS 2005 properties.settings. I might just wait and see if anyone has a solution using this but if no avail, might rewrite using the Application Block configuration.
Wednesday, May 03, 2006 5:24 AMModerator
I think I would try putting the values in the Settings Editor, and mark them all as "User" settings. This makes them writable, and makes them persist through upgrades. You can even generate some UI to edit the values within the app, which could be a nice experience.
Wednesday, May 03, 2006 8:18 AMThe problem is that ClickOnce applies some sort of checksum on every file, to prevent any tampering. Unfortunately this means you cannot modify the config file in any way after publishing.
I'm afraid the best solution I've found is not to use the config file for volatile settings, but supply a reference in the config to another (xml) file in a shared location - which is therefore not managed by ClickOnce.
Wednesday, May 03, 2006 5:25 PMCannot the manifest be re-generated (re-signed) after publishing using the mage tool, so even if the config file is manipulated after publishing till the time it is re-signed using the original certificate created during the ClickOnce publishing, one would assume it should work would it not !!
Wednesday, May 03, 2006 9:45 PM
Thanks for your reply David.
In the scenario I've described above the issue is really how our customer will set the configurable settings before they deploy to their users. When producing applications in-house this would not be a problem, however our customer will not be able to rebuild the application nor would want to set the configurable settings for each installation via the app itself.
Do you know of a way our customer would be able to change the settings before deployment?
Wednesday, May 03, 2006 10:01 PM
Thanks for your reply Brian.
I found out about the checksum the hard way after attempting to change the config file manually. VS 2005 compiles the app.config settings into the Settings.settings class itself so that it uses the compiled value if the app.config value is missing and perhaps changed (I still have to check how this actually works though).
I think your solution of a separate file may be the only way out using click-once but I am very surprised that the scenario I described is not more elegantly catered for by Microsoft - it must be a common problem. Perhaps click-once is not meant for service providers rather in-house development only.
Maybe use of Windows Installer and registry settings is still the best method for applications built by service providers (or Wise installer etc).
Can I ask where you have stored the common settings (xml).. wouldn't you still have to hard-wire this location into the app.config before deployment?
Thursday, May 04, 2006 5:43 AMModerator
I see, I kind of misunderstood. I thought the end-user would be the one reconfiguring.
The rest of the thread appears on track, you can't really do this without using Mage to update and resign the manifests.
The main reason is that this provides some security against manipulations and spoofing attacks. If the file could be changed before the user installs it, then they could be subject to a malicious attack.
Hope this helps clarify things.
Thursday, May 04, 2006 8:35 AMHi David. Yes, I store a reference url for the shared settings file in the app.config, but of course this also needs modification for each installation. In my case, my applications are typically only installed in one location (a group file server), so I can predetermine this before publishing the app.
One way to support more than two configs is to use custom Build settings, and post-build events to copy over the relevant config for each customer, but that doesn't work well with ClickOnce either...
Tuesday, May 09, 2006 4:45 PMI am in a similar position.
I have finally moved from vb6 to vb.net, I have created an application that has an associated app.config with it. I build an installer project for the application, I used one of the custom forms to accept a variable input which let me add a command line parameter dynamically to the shortcut the installer created.
However I have db connection details in the app.config (well it's applicationame.exe.config as its using class namespace).
I would have preferred a way with the installer project to allow runtime variable replacement within the app.config file.
I can actually manually update the applicationname.exe.config file after the installation and it allows the changes. This is not much use though when 110 clients need updating.
Is there an easy way, with the Installer project, to update the file?
Do I have to create another application that allows the app.config name entry and variables to replace?
Seems shortsighted of MS this, unless (more than likely) I have missed the bit in the help file explaining how (Bloaty help system that does not help much!)
Wednesday, May 10, 2006 4:39 AMModerator
The scenario you describe is using Setup projects is a little different than the ClickOnce scenario. However, there isn't a built-in solution for changing installed .config files.
Unfortunately, at this time, you'll need to craft a solution. We have a walkthrough that it sounds like you've already found on how to do it during install, so there's some sample code about how to load and edit the .config file.
Now, if you get kind of slick, you can setup a Web Service that your app connects to... and instead of using App.Config edits use "User" settings so that you can use My.Settings.XXX to read/write them. Then, your app can contact the Web Service and get any changes to settings you want to roll out, and the app can update itself.
Friday, April 03, 2009 7:31 PMI have been programming in asp.net (WEB) since 2002 and I am so used to using app.config that I naturally thought about using app.config to store some info and I can change the app.config to allow more flexibility in the program. Now I learnt that is not a good idea.
MSFT does not want client change app.config so that the behaviour of all clients would be the same. To extend your client behiour, you have to release a new version.