Reputation: 9003
How do people commonly store local .settings files for their projects? For example, I have a solution for a web project in Mercurial. I have a data project containing my entities and repositories. My connection string is stored in Settings.settings and I'd like to have different sources depending on my location.
I was thinking I could simply move the file to Settings.settings.global and requiring anyone to change it when they clone my repo. Is there a better way of going about this? What are the best-practices for handling such things in Visual Studio?
One concern of mine with simply renaming the Settings.settings file containing my data source is that Visual Studio seems to automagically modify my app.config with the new values and I'm not sure how that will be handled if I force people to rename.
Upvotes: 3
Views: 2372
Reputation: 13276
Not sure about .settings
files, but for .config
files and any other projects I'm using a file like app.config.sample
which is included in the repository, along with a .cmd
script which is creating the app.config
file on run.
After cloning and running the .cmd
script, any developer can customize the app.config
as needed.
Off-topic: everyone I've asked advised me to keep the connection strings in app.config
/web.config
, but YMMV.
Some links:
Upvotes: 1
Reputation: 50690
I'm not clear on whether your organization is using revision control or not, but generally speaking, the .settings
file committed to your revision control server contains some generic settings (or more specifically, testing or production settings). Then, each developer simply checks out the project, modifies .settings
freely to suit their local configuration, and never submits the changes back to the revision control server. Everybody's happy!
Upvotes: 2