Gav*_*vin 161 .net c# vb.net asp.net configuration
我有一个.NET应用程序,它具有用于Debug和Release版本的不同配置文件.例如调试app.config文件指向一个发展的SQL Server具有调试启用,并公布目标指向活的SQL Server.还有其他设置,其中一些在调试/发布中有所不同.
我目前使用两个单独的配置文件(debug.app.config和release.app.config).我在项目上有一个构建事件,它说如果这是一个发布版本,那么将release.app.config复制到app.config,否则将debug.app.config复制到app.config.
问题是应用程序似乎从settings.settings文件中获取其设置,因此我必须在Visual Studio中打开settings.settings,然后提示我设置已更改,因此我接受更改,保存settings.settings并具有重建以使其使用正确的设置.
是否有更好/推荐/首选的方法来实现类似的效果？或者同样,我接近这个完全错误并且有更好的方法吗？
Por*_*man 61
任何可能因环境而异的配置应存储在计算机级别,而不是应用程序级别.(有关配置级别的更多信息.)
这些是我通常在机器级别存储的配置元素:
当每个环境(开发人员,集成,测试,阶段,实时)在c:\ Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG目录中都有自己的唯一设置时,您可以在环境之间升级应用程序代码而无需任何环境构建后的修改.
很明显,机器级CONFIG目录的内容在不同的存储库或与您的应用程序不同的文件夹结构中进行版本控制.您可以通过智能使用configSource使您的.config文件更加源代码控制.
我已经这样做了7年,在25个以上不同公司的200多个ASP.NET应用程序上.(不要试图吹嘘,只是想让你知道我从未见过这种方法不起作用的情况.)
小智 51
这可能对某些处理Settings.settings和App.config的人有所帮助:在编辑Visual Studio中的Settings.settings网格中的任何值(在我的情况下为Visual Studio 2008)时,请注意"属性"窗格中的GenerateDefaultValueInCode属性.
如果将GenerateDefaultValueInCode设置为True(True是默认值!),则默认值将编译到EXE(或DLL)中,当您在纯文本编辑器中打开它时,可以在文件中找到它.
我正在研究控制台应用程序,如果我在EXE中有默认值,应用程序总是忽略配置文件位于同一目录中!相当噩梦,并没有在整个互联网上的这方面的信息.
Eri*_*ard 34
这里有一个相关的问题:
配置文件有一种覆盖设置的方法:
<appSettings file="Local.config">
相反,在两个文件(或更多)检查,只检查默认的配置文件,然后将每个目标机器上,你把Local.config,只有拥有该特定机器覆盖appSettings部分.
如果您使用的是配置部分,则等效于:
configSource="Local.config"
当然,从其他机器制作所有Local.config文件的备份副本并在某处检查它们是个好主意,但不能作为实际解决方案的一部分.每个开发人员在Local.config文件上放置一个"忽略",因此它不会被检入,这会覆盖其他人的文件.
(你实际上不必称它为"Local.config",这就是我使用的)
Ste*_*ams 14
从我正在阅读的内容来看,听起来您正在使用Visual Studio进行构建过程.您是否考虑过使用MSBuild和Nant？
Nant的xml语法有点奇怪但是一旦你理解了它,做你提到的就变得非常微不足道了.
<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>
Mag*_*son 11
对我来说,似乎您可以从Visual Studio 2005 Web部署项目中受益.
有了它,您可以告诉它根据构建配置更新/修改web.config文件的各个部分.
请查看Scott Gu的博客文章,以获得快速概述/示例.
我们曾经使用过Web部署项目,但后来迁移到了NAnt.我们目前将配置值直接嵌入到构建脚本中,并通过xmlpoke任务将它们注入到我们的配置文件中,而不是分支和复制不同的设置文件:
<xmlpoke
file="${stagingTarget}/web.config"
xpath="/configuration/system.web/compilation/@debug"
value="true"
/>
在任何一种情况下,您的配置文件都可以包含您想要的任何开发人员值,并且它们将在您的开发环境中正常工作,而不会破坏您的生产系统.我们发现开发人员在测试时不太可能随意更改构建脚本变量,因此偶然的错误配置比我们尝试过的其他技术更少见,尽管仍然需要在过程的早期添加每个var,以便默认情况下,dev值不会被推送到prod.
我当前的雇主首先将dev级别(debug,stage,live等)放在machine.config文件中解决了这个问题.然后他们编写代码来选择并使用正确的配置文件.这解决了部署应用程序后错误连接字符串的问题.
他们最近写了一个中央Web服务,它从machine.config值中的值发回正确的连接字符串.
这是最好的解决方案吗？可能不是,但它适用于他们.
其中一个对我有用的解决方案是使用WebDeploymentProject.我在我的站点中有2/3个不同的web.config文件,并且在发布时,取决于所选的配置模式(发布/暂存/等...),我将复制Web.Release.config并将其重命名为web.在AfterBuild事件中配置,并删除我不需要的那些(例如Web.Staging.config).
<Target Name="AfterBuild">
<!--Web.config -->
<Copy Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\Web.Release.config" DestinationFiles="$(OutputPath)\Web.config" />
<Copy Condition=" '$(Configuration)|$(Platform)' == 'Staging|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\Web.Staging.config" DestinationFiles="$(OutputPath)\Web.config" />
<!--Delete extra files -->
<Delete Files="$(OutputPath)\Web.Release.config" />
<Delete Files="$(OutputPath)\Web.Staging.config" />
<Delete Files="@(ProjFiles)" />
</Target>