当前位置：文江博客话题详情

升级时的 web.config 最佳实践

发布于 2024-10-18 02:18:50 字数 192 浏览 2 评论 0原文

我发送一个应用程序，让客户在 web.config 中更改连接字符串等。

当我升级我的应用程序时，这会引起烦恼，因为我不想用我的值覆盖它们的值。

当 .net 版本升级时，这尤其糟糕。

人们通常如何处理这种情况？

例如，他们是否以某种方式将 web.config 拆分出来，以便客户数据不再是其中的一部分？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

鼻尖触碰 2024-10-25 02:18:50

我从未听说过有人让 web.config 可供客户或任何其他业务人员访问和写入。你只是自找麻烦。

听起来您可能想要开发一个小型前端（Web）实用程序，以允许他们以表单形式提交值并将其保存到数据库中。然后让您的应用程序访问数据库来获取这些值，而不是 web.config。

这似乎更多是一个内容管理问题。

回复收藏 0 原文

对风讲故事 2024-10-25 02:18:50

将您的配置文件分成两个。一个为您，另一个为您的客户。
客户可自定义的所有配置都会进入客户配置文件，其他所有内容都会进入您的配置文件。

这将使您可以轻松升级/修改您的配置文件，而无需覆盖客户的配置文件。

您可以使用 SectionInformation.ConfigSource 元素来声明关联的配置文件。这篇博文向您展示如何做到这一点。

我什至在此项目中使用它来检测 ASP.NET 中外部配置的更改。

回复收藏 0 原文

凉墨 2024-10-25 02:18:50

有几种方法可以处理这个问题。我会提到两个。其中之一涉及您的交付过程。另一个实际上涉及到web.config。

1) 不要将 web.config 作为“代码”发送。将其视为“配置”。这并不适用于所有场景（事实上，基于客户的场景是我想到的糟糕场景）。如果您要交付给“生产”，您可以同意让他们对 web.config 的内容负责（一个好的做法是尝试尽可能多地重构 machine.config）。这样，连接字符串之类的事情就会成为生产问题，而不是开发问题。

2）使用configSource属性。 ASP.NET 2.0 支持使用 configSource 属性来外部化属性。将所有 web.config 作为“生产问题”进行处理可能很困难（在交付给客户的情况下，他们可能不是这方面的专家）。

所以你像这样外部化它。这是您当前的 appSettings 部分，例如：

<appSettings>
  <add key="EnableFrobbing" value="false" />
  <add key="ExpectFooingFrom" value="[email protected] " />
</appSettings>

如果您想要外部化这些设置，以便您的新货件不会覆盖客户设置，请将其替换为：

<appSettings configSource="App_Data\WebConfigXML\appSettings.xml"/>

据我所知，仅在此处相对路径。

参考文献：（

显示该属性是 ASP.NET 2.0 中的新属性）
http://msdn .microsoft.com/en-us/library/system.configuration.sectioninformation.configsource%28v=VS.80%29.aspx

http://www.codeproject.com/KB/aspnet/Manage_Webconfig.aspx

http://trycatchfail.com/blog/post/2008/09/25/Webconfig-magic-configSource-and -文件属性.aspx

There are a few ways to handle this. I'll mention two. One concerns your delivery process. The other actually involves the web.config.

1) Don't ship the web.config as "code". Consider it "configuration". This doesn't apply well to all scenarios (in fact, a customer based scenario is the bad scenario I was thinking of). If you are delivering to "production" you can agree to make them responsible for the contents of web.config (and a good practice there is to try and refactor as much as you can to machine.config). That way, things like the connection string become production concerns and not development concerns.

2) Use the configSource attribute. ASP.NET 2.0 supports externalizing attributes with the configSource attribute. It can be hard to turn over ALL of the web.config as a "production concern" (in a delivery to customer scenario, They may not be experts in all of this).

So you externalize it like this. Here is your current appSettings section, for example:

<appSettings>
  <add key="EnableFrobbing" value="false" />
  <add key="ExpectFooingFrom" value="[email protected] " />
</appSettings>

If these are settings you want to externalize so your new shipments don't override customer settings, replace it with this:

<appSettings configSource="App_Data\WebConfigXML\appSettings.xml"/>

Relative paths only here as far as I know.

References:

(Shows the property is new in ASP.NET 2.0)
http://msdn.microsoft.com/en-us/library/system.configuration.sectioninformation.configsource%28v=VS.80%29.aspx

http://www.codeproject.com/KB/aspnet/Manage_Webconfig.aspx

http://trycatchfail.com/blog/post/2008/09/25/Webconfig-magic-configSource-and-file-attributes.aspx

回复收藏 0 原文

酒中人 2024-10-25 02:18:50

你有几个选择。在我看来，最好的办法是当您将应用程序推送到其环境时不要发布 Web 配置。如果需要编写新的配置部分/设置，您可以封装一些逻辑，以编程方式在一个小帮助应用程序中编写新配置，并将其作为部署后操作运行，或者您可以将新设置粘贴到 e - 邮件并发送给您在另一端信任的人以将其放入配置中。在 99% 的情况下我会建议不要使用第二种选择；很可能会出现交叉线或被忽略的情况，那么当系统因配置未成功而出现故障时，这就是您的错。

回复收藏 0 原文

~没有更多了~