【问题标题】:Different app.config for ClickOnce applicationClickOnce 应用程序的不同 app.config
【发布时间】:2010-02-01 09:06:58
【问题描述】:

我们有一个 ClickOnce 部署的应用程序部署在 2 个不同的地方。 两者都需要在 app.config 中进行一些不同的设置(除了开发环境)

现在生成这些安装的过程是让某人从 Visual Studio 手动更改这些设置并重新构建。这当然是一种痛苦。

有些人建议我们在我们的解决方案中创建一个额外的项目,该项目几乎只包含 app.settings 并在另一个项目中运行主窗体。

人们如何处理这个问题?

(我正在寻找具体的解决方案/示例,“使用自动构建系统”可能是目标,但它不是很具体..)

【问题讨论】:

  • 一些相关信息here.

标签: .net configuration clickonce


【解决方案1】:

我认为有两种解决方案:

  • 如您所说,创建一个多项目。该项目基本上代表了正确的 app.config、正确的部署配置等。否则它只是将代码流委托给“真实”项目。
  • 另一种可能性是创建多个 app.config 文件。像 app-develop.config => Develop-Version、app-productive.config => Productive-Version、app-other-thing.config... 现在您要向 MSBuild 文件 (.csproj) 添加一个附加任务它将正确的 app-*.config 复制到 app.config 文件中。我们在日志配置中做了类似的事情,它工作正常。

【讨论】:

    【解决方案2】:

    我会将这些设置移出 app.config。在 ClickOnce 更新期间,我们在维护配置设置值方面遇到了许多问题,我不再相信它了。我会将这些设置移动到轻量级数据库中,例如 SqlLite 或 SqlCe,然后将其与您的应用程序一起分发。然后维护设置只是在数据库中填充不同的值。

    【讨论】:

    • 接下来如何根据环境配置数据库中的值如何设置?例如,您的数据库如何知道(或被告知)它位于开发环境而不是测试/生产环境中?
    【解决方案3】:

    我有blogged about our solution ,效果很好。

    基本上我们有一个单独的文件,其中包含每个环境的所有配置信息(即不同的部署位置),构建过程使用此信息在配置文件/本地数据库中设置值。

    该解决方案不会干扰开发人员的日常活动,并且适用于 ClickOnce 部署(即在清单签名之前更新配置文件)。

    让我知道您对解决方案的看法...好还是坏:-)

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2010-10-24
      • 1970-01-01
      • 2016-01-09
      • 2012-02-03
      • 2011-07-16
      • 1970-01-01
      • 2015-04-17
      • 1970-01-01
      相关资源
      最近更新 更多