现在我以前在 SO 上以不同的方式看到过这个问题,但令人惊讶的是不是这种形式:
我有一个包含多个需要相互通信的 Web 服务(项目)的解决方案。在发布这些 Web 服务中的每一个之后,最终可能会在具有不同数据库的不同机器上结束。为了告诉每个 Web 服务所有其他 Web 服务在哪里,我想在开发过程中维护一个配置文件。
我希望在发布配置后会出现在每个已发布的项目中。而且我希望配置文件在发布后是可编辑的,这样我就可以快速迁移某个 Web 服务,然后只需编辑其他 Web 服务的所有配置文件。
我不想在数据库中执行此操作,因为配置文件本身也应该保存与数据库的连接设置。
我遇到了以下想法/想法/问题:
- 我有一个名为“common”的 dll 项目,它被其他项目引用。让我们给它一个 shared.config 并在该项目中构建一个类,该类可用于读取 shared.config
System.Configuration.ConfigurationManager.OpenExeConfiguration("shared.config")
。只需要确保 shared.config 将与 DLL 一起发布。
我喜欢这个解决方案,因为它还可以让我在每个项目中保留一个 web.config,其中只有项目特定的设置。并让 shared.config 具有共享设置。但是我在 SO 上读到,这不应该被轻视,并且可能会产生一些不需要的副作用,例如文件访问问题;虽然我想知道这是否适用于我的情况。另外,我想请你帮忙看看如何实际实现这一点,因为我认为 Visual Studio 不支持开箱即用的 DLL 项目的 app.config。
- 我还考虑在解决方案项中创建一个 shared.config 文件。然后在每个项目中链接该文件。并在每个项目的Web.config中,添加:
<appSettings configSource="shared.config" />
指向该项目中的链接文件。
虽然我找不到任何不这样做的理由,但第一次实施失败了。似乎(至少在开发过程中),c# 找不到链接的 shared.config 文件。我猜链接文件不会立即完成,也不会在创建链接文件后维护,但文件仅在我发布时复制到项目中。从而使文件在开发过程中丢失。这个对吗?