I'm wondering if there is a way to create settings in a config file for individual programmers. The situation I'm encountering is that there are some programmers who want settings turned on and several that want them turned off. Our config files are in SVN source control, so using a shared config file means we are always overwriting each others settings. We are doing this for an ASP.NET web application project. My initial thoughts would be to create a config file outside of source control, but how do I make it so that each programmer has his own copy?
Here is some further clarification. We have a link in the main web.config file that points to an environment-based file (e.g. file used for dev, staging and live).
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings configSource="EnvironmentConfigs\appSettings.config" />
...
</configuration>
Inside the appSettings.config file, we have settings for dev, staging and live. What I'd like to do is create another config file called user.config and have the individual programmer settings staored there (not in source control of course). What do I need to do in order to have visual studio read from this new file?
The settings file does not need to be versioned in SVN, or each developer can select their settings file to not be overwritten or committed. See the SVN settings file, it could even be added as a global ignore.
Each developer can set up their own build congifuration in Visual Studio. This build configuration should be linked to a build script, which replaces sections of the Web.Config/App.Config/*.Config files specifically as the developer wants.
This way, when they want to make changes to the config files to suit themselves, they should change the replacements in the build script rather than changing the config file directly.
This article covers some of the points i've mentioned: http://www.diaryofaninja.com/blog/2010/05/09/automated-site-deployments-with-teamcity-deployment-projects-amp-svn
Remove the config file from source control and set the svn:ignore property on it. Then it won't be committed. Then, also create another file, like, Production.web.config, that has the production values in it, so you still keep those around too.
That's what I do!
Don't commit config file changes unless they are new settings that to be sent to everyone.
Otherwise, checkout, edit, and leave it checked out. You'll know if someone else has added/modified the file when you get latest version. At which time you merge your settings with their changes, but leave it checked out on your machine.
We do not store application configuration files in source control. Instead, in source control, we store a configuration file template, usually named something like web.config.template. Each developer has their own 'values' file, usually named web.config.values-bem for instance. Each developer also sets up a post-commit hook which takes the template file, and processes it, replacing 'variables' with their values from the specified values file.
For instance, my config values file has the following definition in it:
DB_SERVER=.\SQLEXPRESS
In the web.config.template file, this exists:
connectionString="server=#DB_SERVER#[DEV1];Persist Security Info=True;Password=#DB_PW#;User ID=#DB_USER#;database=#DB_NAME#;Enlist=false;Max Pool Size=100" />
So when the process runs (a python script), it replaces all instances of #DB_SERVER# with the setting I have in my values file. The template script allows for default values to be specified right in the template as well, so you can make changes to the template file and not break other developers' environments (usually). (The default values are next to the variable, in square brackets.)
This solution allows each developer to have their own settings, but still have a web.config.template file that's versioned, and each developer avoids 'inflicting' configuration changes on other developers.
This works well for us. If you want to use the same scheme, you can check out the code for it on my github: https://github.com/bmontgomery/FileReplace. I can help you with the hook scripts as well if you're interested in that.
Related
We are working with two different teams on the same project. In a configuration file App.config, we have two connections string with our connection settings to connect to our database and the second team has another database with a different connection string. I have to comment the second connection string and uncomment the first. I have to check always this file if the connection string is correct (if the another team has not commited this file). It's a little bit boring..
This configuration file contains some other configurations keys that we use in common. My goal is to set (on the config file with a or somewhat) to tell to SVN to not include this part of file when I made a commit.
Is it possible ?
Partial file commits aren't possible in any version tracking system I've ever seen. You can however take a look at something like this if you're using VS2010.
You can use the configSource attribute to have ASP.NET read the config from an external file instead of the main config file. That way you can have one dirty and ignore-on-commit file containing the connection strings, and still be able to commit the main config file when changes are needed.
I suggest that everyone in your teams backup the configuration file, and have someone rename the file in SVN to something like template.[original-name] and commit that.
Then, have everybody restore their own configuration file and put in into the svn:ignore Subversion property of the directory containing the file, and commit that directory to have the svn:ignore in version control for everyone and have them update their working copies after that.
This way, each team member can have a different configuration.
Configuration and user/system specific files should not be in version control.
See also http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.ignore.html.
EDIT: To actually answer your question, David is right, partial file commits are not possible (and usually would not make sense either). It is not the intended workflow of Subversion.
How can I overwrite the app.config file form the App Data folder with the default one by code?
Not sure what you mean but you can use at the configurationSettings class to manage settings, you can also use a simple Data.XML namespace and change the XML in the config file and save it back but just beware that it is not the recommanded.
typically i have always created an config object that i read all the config file settings and use it as a singleton in my code. if you want you can add a save method to the class that saves back the config file if you want to persist the changes that your code makes to the config class.
You can use a settings file. The VS designer will generate a proxy class for you. For each entry you can specify in the properties window wether you want to "GenerateDefaultInCode" or not. This way, you can configure your settings in the app.config file under the "ApplicationsSettings" section and at the same time rely on default values (set via attributes in the proxy class) in the generated code.
See http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx for how to add a .settings file to your project.
As pointed out here default values should be used with care because they can lead to error-prone behaviour when you deploy to a different environment.
I can't see anything on here but I do remember being told that If you want an application to update a config file then it needs to be under ...
**C:\Users\Ibrar Mumtaz\AppData**
Well somewhere there, the reason being is that the user should have permisions to update a config file here and not under the applications install folder. This is the impression that I am under and I'm fairly certain that this is definately the case. As I think I read that on here = p
My question is, is there anybody on here that can shine some light on this as this is the last feature I want to implement before I give my application out to test.
1) First thing is, an installer is needed to set up the folder and then drop my apps config file into it. I already am using the visial studio installer so I have my app packaged up but this point is throwing me off? How do I do this then? I just need someone to show how to do this and I should be O.K reconfiguring my app to look for the new home of the config file.
2) I should be able to work out how to find the folder and locate the config file found within it. As once I know the installer is chucking the config file out into the right folder where the user has permissions then it should be straight forward from there.
Thanks for reading.
UPDATE:
It was pretty straight foward, as the VS Installer has an option to add a special folder so all that was left was to access the folder programmatically and read and write to the config file. ONE PROBLEM? The ConfigurationManager class which I have used to create my config file for my application expects my config file to be local to the application and not miles away in a completey different part of the local FileSystem? Errr help here Plz?
Ibrar
If you are using the VS Settings file to create application setting keys, and have values that the user might want to change in runtime, and save his preferences, just set the scope of those settings to "User" instead of "Application".
That way you will have a setter method for them, and you can edit the Settings.Default instance, and when you are done call the Save() method to persist them to disk.
The file will be saved in the user's "AppData" folder, wherever it is, under some cryptic folder. But you needn't worry about it's location most of the time, since it will be read automatically on the next execute, and persisted to the same location on subsequent runs.
Afaik the installer can be extended with classes that do things.
On INSTALL-action to do could be to
var path = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData),
"My app name");
if (!Directory.Exists(path)) Directory.CreateDirectory(path);
And vice-versa on uninstall.
App.config files are related to where the physical assembly is located I think.
Actually, if your app is running on the user's machine- it will have whatever permissions that user has. So most likely, you can expect to be able to write anywhere on the file system.
However it is possible the user would be running under a restricted acct, and thus not have the permissions. So you could just use the registry to store where your config file is (install folder), then when you try to update it, if it fails for permissions, ask the user to grant it.
Or you could use the Windows standard folders, as you were getting at, because doing so also separates out user data from application data.
Use the Environment.GetFolderPath () method to get the 'special folder' paths in your app.
http://www.programmersheaven.com/2/Les_CSharp_15_p2
http://msdn.microsoft.com/en-us/library/14tx8hby.aspx
If you are talking about application settings found on project Properties -> Settings tab, then there're two different types of settings: user-level and application-level.
If you need to change any settings in run-time, these would be user-level settings (http://msdn.microsoft.com/en-us/library/cftf714c.aspx) and all changes would be buried somewhere in the private folder in your user profile.
If you want to update application-level settings, your best shot would be to do that during software installation. In this case you don't need to look for the configuration file (YourApp.exe.config) anywhere but in the application folder. More likely you would need to create some sort of post-install event handler in your setup package and run some script or another application which would update data in YourApp.exe.config. Everything in the setup package will be executed with elevated priviledges and thus that configuration file would be writeable. BTW, this scenario applies to 2000 and XP, if the user is using limited user account type priviledges.
Because I did not technically find the answer I was looking for, after 6 months I have come back to my application and have managed to produce a solution that does not break my current architecture.
If you are implementing an application to make use of some of the features on offer by the ConfigurationManager then it offers a static method called:
ConfigurationManager.OpenMappedExeConfiguration(); // takes two arguements.
It can be used like this:
ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
fileMap.ExeConfigFilename = returnUsersAppDataFolderPath();
Configuration config = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);
e.g
fileMap.ExeConfigFileName = #"some file path external to your applications install folder."
remember to use '#' symbol in front to allow the compiler to literally treat the string on as is basis.
If the config file can be conveniently locally located then just use the:
ConfigurationManager.OpenExeConfiguration(string exePath)
Above is what you would typically use but for me i needed my config file to located under the users AppData folder so the first option is what I needed. And it does indeed work.
I hope this helps others as it does for me as I want to deploy my application to Win7 and vista environments therefore this question needed asking if I was to stick to using the ConfigurationManager it's a shame the method of choice in the end never really stood out in the first place = ).
If you want to read from your config file then leave a comment and I will show you how I managed to do that also.
I'm writing applications that interoperate with a third-party application. This application exposes an API to developers via methods in a DLL. Some time ago, the vendor of this app started integrating their own .NET components into their program, and when they did, they decided that their components should use the ConfigurationManager to get settings at runtime.
What this means: their program, foo.exe, calls fooengine.dll, and it reads its settings from foo.exe.config. My program, bar.exe, also calls fooengine.dll, and it reads its settings from bar.exe.config.
Well, that's just plain wrong. But how do I fix it?
The simple workaround is to replicate foo.exe.config's settings in bar.exe.config. That'll work, but it's stupid. It means that from an administrative standpoint, a given setting has to be maintained in N different files. That's going to fail sooner or later.
I tried putting a configSource attribute on the appSettings section in my config file. (As it happens, I'm using the applicationSettings section for my settings, and they're using the appSettings section for theirs, so I can live with simply getting that section from a different file.) But the ConfigurationManager doesn't like that: it wants the path in configSource to be not only relative to but below my program's directory.
I can physically read their settings file into an XmlDocument and then set them myself. But now I'm tightly coupling my code to their implementation; if they put out a new release that moves the settings to the applicationSettings section (which is where they should be now that it's 2009), my code will break.
Is there another way out of this?
Okay, I think I've found the answer, at least for my specific version of this problem.
The .NET 2.0 ConfigurationManager supports a file attribute on the appSettings element. This lets you get the contents of that element from an external file. So what I do is:
Cut the appSettings element out of foo.exe.config and paste it into another file in that directory called, let's say, appSettings.xml.
Add a new element to foo.exe.config: <appSettings file="appSettings.xml"/>.
Add an element to bar.exe.config: <appSettings file="c:\program files\foo\appSettings.xml"/>
This works. But it only works because my program doesn't use appSettings at all.
You could just load their configuration file.
I know it is a good idea to store configuration data in app.config (e.g. database connection strings) instead of hardcoing it, even if I am writing an application just for myself. But is there a way to update the configuration data stored in app.config from the program that is using it?
If you use the Settings for the project, you can mark each setting as either application or user.
If they're set as user, they will be stored per-user and when you call the Save method it will be updated in the config for that user.
Code project has a really detailed article on saving all types of settings.
app.config isn't what you want to use for user-tweakable data, as it'll be stored somewhere in Program Files (which the user shouldn't have write permissions to). Instead, settings marked with a UserScopedSettingAttribute will end up in a user-scoped .config file somewhere in %LocalAppData%.
I found the best way to learn this stuff was to mess with the Visual Studio "Settings" tab (on your project's property pages), then look at the code that it generates and look in %LocalAppData% to see the file that it generates.