Greetings forum inmates
Consider the following scenario:
You have created your application and you want to deploy it either via click once or xcopy - emphasis goes on xcopy for my case though.
Normally you should include an app_name.exe.config file within the download so that the settings are included and loaded when the application starts. But what if you may have a different set of settings attributes on each deployment situation One solution is ofcourse to provide in the download a .config file with <appsettings> for each and every thing that can be changed. The other solution is to create an app_name.exe.config file programmatically.
I am sure that within System.Configuration lies the answer (perhaps XmlDocument ) but if there was an automatic generator or what-not it would be most appreciated.
Could someone nudge me to the right direction The ideal scenario would be to have a foo.exe that will run without any properties (considering a try-catch when trying to load settings if the foo.exe.config is not existent) and when something is changed then a foo.exe.config is created - and only then!
Thank you so much for your patience.
Create the app_name.exe.config file during runtime
VKB
First of all thank you so much for taking time for this one.
Second, the deployment scenario includes local file manipualtion, assume at least full read/write capabilties in the Application.ExecutablePath.
So, my only question is: Is there an automatic exe.config generator or do I have to create an XmlDocument and start adding nodes etc etc I *really* would like to avoid deploying a .config file along my app - in some times it is even inappropriate.
And suppose I deploy an empty .config file. Can I use System.Configuration to dynamically add and remove settings from it Not all pcs will have the same configuration settings requests. So (for argument's sake)
PC1:
<appsettings><loss_color = "red"/></appsettings> etc etc
and PC2:
<appsettings><bpl_color = "yellow" /><pol_color="blue" /></appsettings> etc etc
Do you see know the problem I face User1 in PC1 would like to change 1 particular setting and keep it that way and User2 would like to change 2 other, different settings and then keep it that way. Or User2 may finally decide to "reset to default" for pol_color and I would like this node deleted from the .config file. Is this a nice wrapped way to do so (if it is possible in the first place) without using XmlDocument itself
Thank you in advance.
dba_2005_ Rookie
I'm not sure what Taylor means by "standard location". Usually an application has rights to write to the folder it is installed to, unless the user running it is extremely restricted. As long as you understand that any changes to app.config are not picked up until the next time your application is run, your approach should work fine.
NXCX
Basically the idea is that the application is deployed remotely by a colleague of mine through VNC to certain directories. We may click-once it when we get the hang of it but for now its simple .exe & relevant assemblies (.dll) copy-paste situation is all.
Still I was hoping that there would be something like an appsettings generator class.
I could go for the .config file being pasted along with the .exe but I would like to avoid it, my users not being the best in terms of "leave that thing alone, it works as it is". In any case I am sure one of them will come and ask me "what the heck is that .exe.config thing in my application directory". I just like to avoid having them tamper with empty things, thank God they don't touch .exe's and dll's. (Constant nightmare: some one will hear about .net and try to ildasm my .exe... I wonder what I' ll hear then from them!)
Anyways, if u come up with anything post it here, I am still looking for an automatic appsettings generator. If I come up with nothing I will mark your replies as answers.
Thanx in advance.
Mike from symbol
Michael Goldberg
To CommonGenius.com,
The Program Files directory is a secure directory that can not be written to by normal users. This is the initial setting used by Windows XP (I believe W2K had different settings). Therefore no user (by default) can write to this directory irrelevant of what the application wants. There are other locations that have been identified by MS as the appropriate place to store writable data depending upon what you are storing (app-level, user-level, etc). Please refer to SpecialFolder enumeration for the values you should be using for this stuff.
If you chose to give normal users write access to the Program Files directory and/or run as anything other than a normal user then you are simply opening yourself up to potential hackers. Assuming that users are smart enough to secure there own machine is somewhat shortsighted unless you are fortunate enough to be dealing with advanced users. I have known developers who don't even know how to properly secure there machines so even "advanced" users don't always know best.
In all the projects I've worked on I'm required (by management and by the desire to get the Windows logo) to support a default installation of the OS (security-wise) and installation into the default directory (as required by Windows logo). Therefore I stand by my philosophy that you should never expect to have write access to the Program Files directory. Nevertheless this particular question was not specifically related to security and therefore I'll end my discussion of this topic on this question.
Thanks,
Michael Taylor - 1/4/06
benong
What I mean by "standard location" is the Program Files directory. When an application is installed it should default to the PF directory. This directory can not be written to by normal users and everybody should be running as a normal user. In the case of xcopy deployment you can theoretically put the stuff anywhere you want but now a hacker has an open door into replacing your executable with his/her own.
In 2.0 the configuration subsystem supports reading and writing configuration files. Therefore use the configuration subsystem to write the entries out. Prior to 2.0 you will be stuck with the XML subsystem for manually writing out any changes you need.
Personally when I need to generate files I start with a template file that contains the stuff everybody needs (like the processing instructions). If I don't want to directly ship the template file then I embed it as a resource that I can extract and save to the user's machine when I need it. With 2.0 I'd lean toward shipping the skeleton configuration file so that the configuration subsystem works automatically. Then whenever you read a setting it might or might not be there. If it isn't you default, if it is you use the configuration file entry. As needed you simply write the value back out to the configuration file. This saves you from having to verify the config file exists and whatnot every time you want to retrieve something from the file.
Michael Taylor - 1/3/06
Ikky
Definitely possible. If nothing else your app could contain an empty configuration file (processing instructions and whatnot included) that is then populated as needed. Otherwise you can use XmlDocument to autogenerate it. The bigger problem is getting .NET to pick up the changes. It doesn't do that automatically.
However the bigger issue is that you'll probably not have sufficient rights to write to the file. If you put your app in the standard location then normal users can't write to it at all.
Michael Taylor - 1/3/06