blocks|key|1527608|text|我当前的雇主首先将开发级别(调试、阶段、实时等)放入machine.config文件中，从而解决了这个问题。然后他们编写代码来提取并使用正确的配置文件。这解决了应用程序部署后使用错误连接字符串的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1527609|他们最近刚刚编写了一个中央the服务，从machine.config值中的值返回正确的连接字符串。|1527610|这是最好的解决方案吗？可能不是，但对他们来说是有效的。|1527611|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

My current employer solved this issue by first putting the dev level (debug, stage, live, etc) in the machine.config file. Then they wrote code to pick that up and use the right config file. That solved the issue with the wrong connection string after the app gets deployed.

They just recently wrote a central webservice that sends back the correct connection string from the value in the machine.config value.

Is this the best solution? Probably not, but it works for them.

blocks|key|1742690|text|在我看来，你可以从Visual+Studio+2005+Web+Deployment+Project中获益。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1742691|这样，您就可以告诉它根据构建配置更新/修改web.config文件的各个部分。|1742692|请看一下this+blog+entry+from+Scott+Gu，以获得快速概述/示例。|1742693|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx|1|http://weblogs.asp.net/scottgu/archive/2005/11/06/429723.aspx^0|9|15|0|0|0|4|T|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$A|X|B|Y|1|Z]]|C|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]]]

To me it seems that you can benefit from the <a href="http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx" rel="noreferrer">Visual Studio 2005 Web Deployment Project</a>s.

With that, you can tell it to update/modify sections of your web.config file depending on the build configuration.

Take a look at <a href="http://weblogs.asp.net/scottgu/archive/2005/11/06/429723.aspx" rel="noreferrer">this blog entry from Scott Gu</a> for a quick overview/sample.

blocks|key|1527688|text|这里有一个相关的问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1527689|Improving+Your+Build+Process|offset|length|1527690|配置文件提供了一种覆盖设置的方法：|1527691|<appSettings+file="Local.config">|code-block|syntax|javascript|1527692|不需要签入两个(或更多)文件，只需签入默认的配置文件，然后在每台目标计算机上放置一个Local.config，其中只有appSettings部分，其中包含该特定计算机的覆盖内容。|1527693|如果您使用的是配置节，则等效项为：|1527694|configSource="Local.config"|1527695|当然，从其他机器备份所有Local.config文件并将其签入某个地方是一个好主意，但这不是实际解决方案的一部分。每个开发人员都会在Local.config文件上放一个“忽略”，这样它就不会被签入，这会覆盖其他所有人的文件。|1527696|(实际上你不需要叫它"Local.config"，我就是这么用的)|1527697|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/14893/improving-your-build-process^0|0|0|S|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@$D|16|E|17|1|18]]|A|$]]|$1|F|3|G|5|6|7|19|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|1A|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|1B|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1C|8|@]|9|@]|A|$]]|$1|Q|3|R|5|J|7|1D|8|@]|9|@]|A|$K|L]]|$1|S|3|T|5|6|7|1E|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1F|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]]]

There is a related question here:

<a href="https://stackoverflow.com/questions/14893/improving-your-build-process">Improving Your Build Process</a>

Config files come with a way to override the settings:

<pre><code>&lt;appSettings file="Local.config"&gt;
</code></pre>

Instead of checking in two files (or more), you only check in the default config file, and then on each target machine, you put a Local.config, with just the appSettings section that has the overrides for that particular machine.

If you are using config sections, the equivalent is:

<pre><code>configSource="Local.config"
</code></pre>

Of course, it's a good idea to make backup copies of all the Local.config files from other machines and check them in somewhere, but not as a part of the actual solutions. Each developer puts an "ignore" on the Local.config file so it doesn't get checked in, which would overwrite everyone else's file.

(You don't actually have to call it "Local.config", that's just what I use)

blocks|key|1527733|text|根据我所读到的，听起来您正在使用Visual+Studio进行构建过程。你有没有想过改用MSBuild和Nant？|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1527734|Nant的xml语法有点奇怪，但是一旦您理解了它，做您提到的事情就变得非常简单了。|1527735|<target+name="build">
++++<property+name="config.type"+value="Release"+/>

++++<msbuild+project="${filename}"+target="Build"+verbose="true"+failonerror="true">
++++++++<property+name="Configuration"+value="${config.type}"+/>
++++</msbuild>

++++<if+test="${config.type+==+'Debug'}">
++++++++<copy+file=${debug.app.config}"+tofile="${app.config}"+/>
++++</if>

++++<if+test="${config.type+==+'Release'}">
++++++++<copy+file=${release.app.config}"+tofile="${app.config}"+/>
++++</if>

</target>|code-block|syntax|javascript|1527736|entityMap|0|LINK|mutability|MUTABLE|url|http://nant.sourceforge.net/^0|1G|4|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|X|8|@]|9|@]|C|$I|J]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]]]

From what I am reading, it sounds like you are using Visual Studio for your build process. Have you thought about using MSBuild and <a href="http://nant.sourceforge.net/" rel="noreferrer">Nant</a> instead? 

Nant's xml syntax is a little weird but once you understand it, doing what you mentioned becomes pretty trivial.

<pre><code>&lt;target name="build"&gt;
 &lt;property name="config.type" value="Release" /&gt;

 &lt;msbuild project="${filename}" target="Build" verbose="true" failonerror="true"&gt;
 &lt;property name="Configuration" value="${config.type}" /&gt;
 &lt;/msbuild&gt;

 &lt;if test="${config.type == 'Debug'}"&gt;
 &lt;copy file=${debug.app.config}" tofile="${app.config}" /&gt;
 &lt;/if&gt;

 &lt;if test="${config.type == 'Release'}"&gt;
 &lt;copy file=${release.app.config}" tofile="${app.config}" /&gt;
 &lt;/if&gt;

&lt;/target&gt;
</code></pre>

blocks|key|1527772|text|其中一个让我工作得很好的解决方案是使用WebDeploymentProject。我的站点中有2/3个不同的web.config文件，并且在发布时，这取决于所选的配置模式(发布/暂存/等等)。我会复制Web.Release.config并在AfterBuild事件中将其重命名为web.config，然后删除不需要的部分(例如Web.Staging.config)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1527773|<Target+Name="AfterBuild">
++++
++++<Copy+Condition="+'$(Configuration)%7C$(Platform)'+==+'Release%7CAnyCPU'+"+SourceFiles="$(SourceWebPhysicalPath)\Web.Release.config"+DestinationFiles="$(OutputPath)\Web.config"+/>
++++<Copy+Condition="+'$(Configuration)%7C$(Platform)'+==+'Staging%7CAnyCPU'+"+SourceFiles="$(SourceWebPhysicalPath)\Web.Staging.config"+DestinationFiles="$(OutputPath)\Web.config"+/>
++++
++++<Delete+Files="$(OutputPath)\Web.Release.config"+/>
++++<Delete+Files="$(OutputPath)\Web.Staging.config"+/>
++++<Delete+Files="@(ProjFiles)"+/>
++</Target>|code-block|syntax|javascript|1527774|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

One of the solutions that worked me fine was using a WebDeploymentProject.
I had 2/3 different web.config files in my site, and on publish, depending on the selected configuration mode (release/staging/etc...) I would copy over the Web.Release.config and rename it to web.config in the AfterBuild event, and delete the ones I don't need (Web.Staging.config for example).

<pre><code>&lt;Target Name="AfterBuild"&gt;
 &lt;!--Web.config --&gt;
 &lt;Copy Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\Web.Release.config" DestinationFiles="$(OutputPath)\Web.config" /&gt;
 &lt;Copy Condition=" '$(Configuration)|$(Platform)' == 'Staging|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\Web.Staging.config" DestinationFiles="$(OutputPath)\Web.config" /&gt;
 &lt;!--Delete extra files --&gt;
 &lt;Delete Files="$(OutputPath)\Web.Release.config" /&gt;
 &lt;Delete Files="$(OutputPath)\Web.Staging.config" /&gt;
 &lt;Delete Files="@(ProjFiles)" /&gt;
 &lt;/Target&gt;
</code></pre>

blocks|key|1742863|text|我们曾经使用Web部署项目，但后来迁移到了NAnt。我们目前没有分支和复制不同的设置文件，而是将配置值直接嵌入到构建脚本中，并通过xmlpoke任务将它们注入到配置文件中：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1742864|++<xmlpoke
++++file="${stagingTarget}/web.config"
++++xpath="/configuration/system.web/compilation/@debug"
++++value="true"
++/>|code-block|syntax|javascript|1742865|在任何一种情况下，您的配置文件都可以包含您想要的任何开发人员值，并且它们在您的开发环境中可以很好地工作，而不会破坏您的生产系统。我们发现，开发人员在测试时不太可能随意更改构建脚本变量，因此意外的错误配置比我们尝试过的其他技术更少，尽管仍然有必要在过程的早期添加每个变量，以便dev值不会被默认推送到prod。|1742866|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

We used to use Web Deployment projects but have since migrated to NAnt. Instead of branching and copying different setting files we currently embed the configuration values directly in the build script and inject them into our config files via xmlpoke tasks:

<pre><code> &lt;xmlpoke
 file="${stagingTarget}/web.config"
 xpath="/configuration/system.web/compilation/@debug"
 value="true"
 /&gt;
</code></pre>

In either case, your config files can have whatever developer values you want and they'll work fine from within your dev environment without breaking your production systems. We've found that developers are less likely to arbitrarily change the build script variables when testing things out, so accidental misconfigurations have been rarer than with other techniques we've tried, though it's still necessary to add each var early in the process so that the dev value doesn't get pushed to prod by default.

blocks|key|1527823|text|您可以在这里找到另一种解决方案：Best+way+to+switch+configuration+between+Development/UAT/Prod+environments+in+ASP.NET?，它使用XSLT来转换web.config。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1527824|也有一些关于使用NAnt的很好的例子。|1527825|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/132885/best-way-to-switch-configuration-between-developmentuatprod-environments-in-asp#132934^0|G|2E|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

You'll find another solution here: <a href="https://stackoverflow.com/questions/132885/best-way-to-switch-configuration-between-developmentuatprod-environments-in-asp#132934">Best way to switch configuration between Development/UAT/Prod environments in ASP.NET?</a> which uses XSLT to transfor the web.config.

There are also some good examples on using NAnt.

blocks|key|1742919|text|和你一样，我也设置了“多”app.config+--例如app.configDEV，app.configTEST，app.config.LOCAL。我看到了一些推荐的优秀的替代方案，但如果你喜欢它为你工作的方式，我会添加以下内容：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1742920|我有一个|1742921|<appSettings>|offset|length|style|CODE|1742922|对于每个应用程序，我将这个添加到标题栏中的UI+:+from+ConfigurationManager.AppSettings.Get(“<add+key+=+"Env"+value+=+"[Local]+"/>”)；|1742923|我只是将配置重命名为我的目标配置(我有一个包含8个应用程序的项目，其中包含大量的数据库/wcf配置，而不是4个事件)。为了使用clickonce部署到每一个中，我在项目中更改了4个seetings并执行。(这一点我很乐意自动化)|1742924|我唯一的问题是记得在更改后“全部清理”，因为旧的配置在手动重命名后被“卡住”了。(我认为这会解决你的setting.setting问题)。|1742925|我发现这真的很好用(总有一天我会有时间看看MSBuild/NAnt)|1742926|entityMap^0|0|0|0|D|0|1X|11|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@$F|W|G|X|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|Y|8|@$F|Z|G|10|H|I]]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|12|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|13|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|S|$]]

Like you I've also set up 'multi' app.config - eg app.configDEV, app.configTEST, app.config.LOCAL. I see some of the excellent alternatives suggested, but if you like the way it works for you, I'd add the following:

I have a 
 <code>&lt;appSettings&gt;</code> 
 <code>&lt;add key = "Env" value = "[Local] "/&gt;</code>
for each app I add this to the UI in the titlebar:
from ConfigurationManager.AppSettings.Get("Env");

I just rename the config to the one I'm targetting (I have a project with 8 apps with lots of database/wcf config against 4 evenioments). To deploy with clickonce into each I change 4 seetings in the project and go. (this I'd love to automate)

My only gotcha is to remember to 'clean all' after a change, as the old config is 'stuck' after a manual rename. (Which I think WILL fix you setting.setting issue).

I find this works really well (one day I'll get time to look at MSBuild/NAnt)

blocks|key|1527903|text|我们的项目也有同样的问题，我们必须维护dev、qa、uat和prod的配置。以下是我们遵循的内容(仅适用于熟悉MSBuild的用户)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1527904|将MSBuild与MSBuild社区任务扩展一起使用。它包括'XmlMassUpdate‘任务，一旦你给它提供了正确的开始节点，它就可以’批量更新‘任何XML文件中的条目。|1527905|要实施以下操作：|1527906|1)您需要有一个配置文件，其中包含您的dev+env条目；这是您的解决方案中的配置文件。|1527907|2)您需要有一个'Substitutions.xml‘文件，该文件只包含每个环境的不同条目(主要是appSettings和ConnectionStrings+)。不会在整个环境中更改的条目不需要放入此文件中。它们可以位于解决方案的web.config文件中，并且不会受到任务的影响|1527908|3)在构建文件中，只需调用XML批量更新任务并提供正确的环境作为参数即可。|1527909|如下例所示：|1527910|++++
++++<appSettings>
++++++++<add+key="ApplicationName"+value="NameInDev"/>
++++++++<add+key="ThisDoesNotChange"+value="Do+not+put+in+substitution+file"+/>
++++</appSettings>

++++
++++<configuration+xmlns:xmu="urn:msbuildcommunitytasks-xmlmassupdate">
++++++<substitutions>
++++++++<QA>
+++++++++++<appSettings>
++++++++++++<add+xmu:key="key"+key="ApplicationName"+value="NameInQA"/>
+++++++++++</appSettings>++++++++++++
++++++++</QA>
++++++++<Prod>
++++++++++<appSettings>
++++++++++++<add+xmu:key="key"+key="ApplicationName"+value="NameInProd"/>
++++++++++</appSettings>++++++++++++
++++++++</Prod>
+++++</substitutions>
++++</configuration>




++++<Target+Name="UpdateConfigSections">
++++++++++++<XmlMassUpdate+ContentFile="Path\of\copy\of\latest+web.config"+SubstitutionsFile="path\of\substitutionFile"+ContentRoot="/configuration"+SubstitutionsRoot="/configuration/substitutions/$(Environment)"+/>
++++++++</Target>|code-block|syntax|javascript|1527911|根据环境将'$Environment‘替换为'QA’或'Prod‘。你为之构建的。请注意，您应该处理配置文件的副本，而不是实际的配置文件本身，以避免任何可能的不可恢复的错误。|1527912|只需运行构建文件，然后将更新后的配置文件移动到您的部署环境中，就完成了！|1527913|要获得更好的概述，请阅读以下内容：|1527914|http://blogs.microsoft.co.il/blogs/dorony/archive/2008/01/18/easy-configuration-deployment-with-msbuild-and-the-xmlmassupdate-task.aspx|offset|length|1527915|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|0|0|0|0|0|0|0|0|3R|0|0^^$0|@$1|2|3|4|5|6|7|19|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1A|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1B|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1C|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1D|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1E|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1F|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|1G|8|@]|9|@]|A|$Q|R]]|$1|S|3|T|5|6|7|1H|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1I|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1J|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1K|8|@]|9|@$10|1L|11|1M|1|1N]]|A|$]]|$1|12|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]]|13|$14|$5|15|16|17|A|$18|Z]]]]

Our project has the same issue where we had to maintain configs for dev, qa, uat and prod. Here is what we followed (only applies if you are familiar with MSBuild):

Use MSBuild with the MSBuild Community tasks extension. It includes the 'XmlMassUpdate' task that can 'mass-update' entries in any XML file once you give it the correct node to start with.

To Implement:

1) You need to have one config file which will have your dev env entries; this is the config file in your solution.

2) You need to have a 'Substitutions.xml' file, that contains only the entries that are DIFFERENT (appSettings and ConnectionStrings mostly) for each environment. Entries that do not change across the environment need not be put in this file. They can live in the web.config file of the solution and will not be touched by the task

3) In your build file, just call the XML mass update task and provide the right environment as a parameter. 

See example below:

<pre><code> &lt;!-- Actual Config File --&gt;
 &lt;appSettings&gt;
 &lt;add key="ApplicationName" value="NameInDev"/&gt;
 &lt;add key="ThisDoesNotChange" value="Do not put in substitution file" /&gt;
 &lt;/appSettings&gt;

 &lt;!-- Substitutions.xml --&gt;
 &lt;configuration xmlns:xmu="urn:msbuildcommunitytasks-xmlmassupdate"&gt;
 &lt;substitutions&gt;
 &lt;QA&gt;
 &lt;appSettings&gt;
 &lt;add xmu:key="key" key="ApplicationName" value="NameInQA"/&gt;
 &lt;/appSettings&gt; 
 &lt;/QA&gt;
 &lt;Prod&gt;
 &lt;appSettings&gt;
 &lt;add xmu:key="key" key="ApplicationName" value="NameInProd"/&gt;
 &lt;/appSettings&gt; 
 &lt;/Prod&gt;
 &lt;/substitutions&gt;
 &lt;/configuration&gt;


&lt;!-- Build.xml file--&gt;

 &lt;Target Name="UpdateConfigSections"&gt;
 &lt;XmlMassUpdate ContentFile="Path\of\copy\of\latest web.config" SubstitutionsFile="path\of\substitutionFile" ContentRoot="/configuration" SubstitutionsRoot="/configuration/substitutions/$(Environment)" /&gt;
 &lt;/Target&gt;
</code></pre>

replace '$Environment' with 'QA' or 'Prod' based on what env. you are building for. Note that you should work on a copy of a config file and not the actual config file itself to avoid any possible non-recoverable mistakes.

Just run the build file and then move the updated config file to your deployment environment and you are done!

For a better overview, read this:

<a href="http://blogs.microsoft.co.il/blogs/dorony/archive/2008/01/18/easy-configuration-deployment-with-msbuild-and-the-xmlmassupdate-task.aspx" rel="nofollow noreferrer">http://blogs.microsoft.co.il/blogs/dorony/archive/2008/01/18/easy-configuration-deployment-with-msbuild-and-the-xmlmassupdate-task.aspx</a>

blocks|key|1527960|text|这可能会对一些处理Settings.settings和App.config的人有所帮助:在Visual+Studio+(我的例子是Visual+Studio2008)的Settings.settings网格中编辑任何值时，请注意属性窗格中的GenerateDefaultValueInCode属性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1527961|如果将GenerateDefaultValueInCode设置为True+(此处的默认值为True！)，则会将默认值编译为可执行文件(或动态链接库)，当您在纯文本编辑器中打开文件时，可以发现它嵌入到文件中。|1527962|我在一个控制台应用程序上工作，如果我在EXE中设置了默认值，该应用程序总是忽略同一目录中的配置文件！这是一场噩梦，整个互联网上都没有关于这方面的信息。|1527963|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

This might help some people dealing with Settings.settings and App.config: Watch out for GenerateDefaultValueInCode attribute in the Properties pane while editing any of the values in the Settings.settings grid in Visual Studio (Visual Studio 2008 in my case). 

If you set GenerateDefaultValueInCode to True (True is the default here!), the default value is compiled into the EXE (or DLL), you can find it embedded in the file when you open it in a plain text editor. 

I was working on a console application and if I had defaulted in the EXE, the application always ignored the configuration file placed in the same directory! Quite a nightmare and no information about this on the whole Internet.

I have a .NET application which has different configuration files for Debug and Release builds. E.g. the debug app.config file points to a development <a href="http://en.wikipedia.org/wiki/Microsoft_SQL_Server" rel="noreferrer">SQL Server</a> which has debugging enabled and the release target points to the live SQL Server. There are also other settings, some of which are different in debug/release.

I currently use two separate configuration files (debug.app.config and release.app.config). I have a build event on the project which says if this is a release build then copy release.app.config to app.config, else copy debug.app.config to app.config.

The problem is that the application seems to get its settings from the settings.settings file, so I have to open settings.settings in Visual Studio which then prompts me that the settings have changed so I accept the changes, save settings.settings and have to rebuild to make it use the correct settings.

Is there a better/recommended/preferred method for achieving a similar effect? Or equally, have I approached this completely wrong and is there a better approach?

.NET Configuration (app.config/web.config/settings.settings)

Visual Studio

SQL Server

数据库

我有一个.NET应用程序，它为调试和发布版本提供了不同的配置文件。例如，调试app.config文件指向启用了调试的开发，而发布目标指向活动的SQL Server。还有其他设置，其中一些在调试/发布中有所不同。我目前使用两个独立的配置文件(debug.app.config和release.app.config)。我在项...

问.NET配置(app.config/web.config/settings.settings)
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问.NET配置(app.config/web.config/settings.settings)EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问.NET配置(app.config/web.config/settings.settings)
EN