Visual Studio 中特定于开发人员的 app.config/web.config 文件

We are using machine.config to avoid having differences in web.config between the environments.

How about ignoring the file, so it never gets checked in? I've run into a similar issue and have added web.config to the ignore list in Subversion.

In TFS though, it's a little bit harder, see this post on how to do it.

One way you could cope is to have a tokenised system and use a rake script to change the values.

A more rudimentary method could be to have a link to an AppSettings.config file for all AppSettings in your web.config (similar with connections) i.e.

<appSettings configSource="_configs/AppSettings.config" />

Then have a folder with each of your developers have a version in a sub folder (i.e. /_configs/dave/). Then when a developer is working on their own code they copy from the sub folder to the root of the linked folder.

You will need to make sure you communicate changes to these files (unless you tokenise). If you keep the AppSettings.config file out of source control and only check in the devs individual folders (all of them) then they will be forced to copy the correct one.

I prefer tokenisation but can be tougher to get up and running if this is only meant to be a quick fix.

In your Web.config use source from other files

<configuration>
<connectionStrings configSource="ConnectionStrings.config" />
...
</configuration>

Keep the web.config in version control and don't do it for ConnectionStrings.config. Now all developers have one file for the connection string.

You can do this for all the settings that are local dependant.

Ignore the files and have a Commom_Web.Config and Common_App.Config. Using a continuous integration build server with build tasks which rename these two to normal names so that the build server can do its job.

We use a system that combines several of the existing answers on this page, plus draws on this suggestion by Scott Hanselman.

In short, what we did was to have a common app.config / web.config, and to have most of the specific settings in individual files, as suggested by other answers here. e.g. for our SMTP settings, the app.config contains

<system.net>
<mailSettings>
<smtp configSource="config\smtp.config" />
</mailSettings>
</system.net>

This file is in source control. However, the individual files, like this, are not:

<?xml version="1.0" encoding="utf-8" ?>
<smtp deliveryMethod="Network">
<network host="127.0.0.1" port="25" defaultCredentials="false" password="" userName ="" />
</smtp>

That's not quite where the story ends though. What about new developers, or a fresh source installation? The bulk of the configuration is no longer in source control, and it's a pain to manually build all of the .config files they need. I prefer to have source that will at least compile right out of the box.

Therefore we do keep a version of the .config files in source control, named .config.default files. A fresh source tree therefore looks like this:

Still, not really any use to the developer, since to Visual Studio they're just meaningless text files. Hence the batch file, copy_default_config.bat, takes care of creating an initial set of .config files from the .config.default files:

@echo off
@REM Makes copies of all .default files without the .default extension, only if it doesn't already exist. Does the same recursively through all child folders.
for /r %%f in (*.default) do (
if not exist "%%~pnf" (echo Copying %%~pnf.default to %%~pnf & copy "%%f" "%%~pnf" /y)
)
echo Done.

The script is safely re-runnable, in that developers who already have their .config files will not have them overwritten. Therefore, one could conceivably run this batch file as a pre-build event. The values in the .default files may not be exactly correct for a new install, but they're a reasonable starting point.

Ultimately what each developer ends up with is a folder of config files that looks something like this:

It may seem a little convoluted, but it's definitely preferable to the hassle of developers stepping on each other's toes.

We have the same problem and what we are doing is

• Check in the web.config with testserver / production values
• Developer goes to windows explorer and change the read only mode of the file
• Edit the config to suit to their environment.
• Check in into the web.config happens only when deployment values changes or any config entry is added or deleted.
• This needs a good amount of comment for each config entry as it needs to be changed by each dev

Assuming you are using Visual Studio, why don't you use different Solution Configurations? For example: you can have a Debug config which uses Web.config.debug and a Release config which uses Web.config.release. Web.config.debug should have something like

<appSettings file="C:/Standard_Path_To_Configs/Standard_Name_For_Config.config">

with the file Standard_Name_For_Config.config that gots all the personal developer settings, while the Web.config.release always has the production settings. You can store default configs in some source controlled folder and make a new user take them from there.

Here a solution for web.config files and Visual Studio 2010:

1) Edit manually your web application .csproj file to add an AfterBuild Target like this:

  <Project>
...
<Target Name="AfterBuild">
<Copy SourceFiles="web.config" DestinationFiles="obj\$(Configuration)\tempweb.config" />
<TransformXml Source="obj\$(Configuration)\tempweb.config"
Transform="web.$(USERNAME).config"
Destination="obj\$(Configuration)\tempweb2.config" />
<ReadLinesFromFile File="obj\$(Configuration)\tempweb2.config"><Output TaskParameter="Lines" ItemName="TransformedWebConfig"/></ReadLinesFromFile>
<ReadLinesFromFile File="web.config"><Output TaskParameter="Lines" ItemName="UnTransformedWebConfig"/></ReadLinesFromFile>
<Copy Condition=" @(UnTransformedWebConfig) != @(TransformedWebConfig) " SourceFiles="obj\$(Configuration)\tempweb2.config" DestinationFiles="web.config" OverwriteReadOnlyFiles="True" />
</Target>
</Project>

This target will transform the Web.config file corresponding to the current developer logged in - hence the $(USERNAME) variable -, with the corresponding file created in 1). It will replace the local Web.config only if the content has changed (to avoid restart) at each build, even if the local Web.config is source controlled, that's why there is the OverwriteReadOnlyFiles is set to True. This point in fact is arguable.

2) Create a file named Web.[developer windows login].config for each developer in the project. (for example in the following screenshots I have two developers named smo and smo2):

These files (1 per developer) can/should be source-controlled. They should not be marked as dependent on the main Web.config because we want to be able to check them out individually.

Each of this file represent a transformation to apply to the main Web.Config file. The transformation syntax is described here: Web.config Transformation Syntax for Web Application Project Deployment. We reuse this cool Xml file transformation task that comes out-of-the-box with Visual Studio. The purpose of this task is merge Xml elements and attributes instead of overwriting the whole file.

For example, here is a sample web.[dev login].config that changes a connection string named 'MyDB', regardless of the rest of the Web.config file:

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add name="MyDB"
connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
</connectionStrings>
</configuration>

Now, this solution is not perfect because:

• after building, developers may have a different Web.Config locally than in the source control system
• they may have to force local write when getting a new Web.Config from the source control system
• developers should not check out/in the main web.config. It should be reserved to few people.

But at least, you only have to maintain a unique main web.config plus one transformation file per developer.

A similar approach could be taken for App.config (not web) files but I did not elaborate further.