【问题标题】:What changes require a dependent assembly to be redeployed?哪些更改需要重新部署依赖程序集?
【发布时间】:2012-09-29 00:29:09
【问题描述】:

在我的工作场所,我们仅通过替换已更改的程序集(不是我的想法)来部署内部应用程序。

我们可以通过查看编译到程序集中的源文件是否已更改来判断我们需要部署哪些程序集。大多数时候,我们不需要重新部署依赖于已更改程序集的程序集。但是我们发现了一些情况,即使程序集中的源文件没有更改,我们也需要重新部署它。

到目前为止,我们知道程序集中的任何这些更改都需要重新编译和部署所有依赖程序集:

  • 不断变化
  • 枚举定义更改(值顺序)
  • 函数的返回类型发生变化,调用者使用 var(有时)
  • 类的命名空间更改为另一个已引用的命名空间。

还有其他我们遗漏的案例吗?我也愿意争论为什么整个方法存在缺陷(尽管它已经使用了多年)。

编辑明确地说,我们总是重新编译,但只部署其中源文件已更改的程序集。

因此,任何破坏编译的东西都会被拾取(方法名称更改等),因为它们需要更改调用代码。

【问题讨论】:

  • 重新编译这么慢,值得这么头痛吗?我至少会在依赖程序集的公共接口发生任何变化时重新编译。
  • 我认为,为了安全起见,您应该在进行更改后重新编译所有内容。但我完全基于直觉。
  • 一切都重新编译,但只部署更改的程序集。
  • 如果你已经重新编译,那么你可以简单地检查编译的程序集是否改变了。
  • @CodeInChaos 假设我可以比较程序集,我将如何可靠地做到这一点?程序集可能会因许多不重要的原因而发生变化,包括源在磁盘上的位置。

标签: c# .net clr


【解决方案1】:

这是另一个:

对可选参数值的更改。

默认值使用它们直接编译到程序集(如果未指定)

 public void MyOptMethod(int optInt = 5) {}

任何调用代码,例如:

 theClass.MyOptMethod();

最终将编译为:

 theClass.MyOptMethod(5);

如果将方法更改为:

 public void MyOptMethod(int optInt = 10) {}

如果要应用新的默认值,则需要重新编译所有依赖程序集。


需要重新编译的其他更改(感谢多项式):

  • 对泛型类型参数约束的更改
  • 方法名称的更改(使用反射时尤其成问题,因为私有方法也可能被检查)
  • 对异常处理的更改(抛出不同的异常类型)
  • 对线程处理的更改
  • 等等……等等……等等……

所以 - 总是重新编译一切

【讨论】:

  • 不错。特别危险,因为调用不会失败,它只会使用错误的值。
  • 还有对泛型类型参数、函数名称(如果您使用反射时甚至是私有的)、异常行为(即抛出 x、y、z 而不是 x、y)的约束的更改,更改为线程安全和其他一大堆为什么你应该总是重新编译的原因。
  • @Polynomial 我认为你不太明白。这些更改将需要调用程序集的更改,因此将包含在部署中。
  • 你最后列出的所有东西都不是我要找的。所有这些都需要更改依赖的汇编代码。我正在寻找东西,除了重新编译之外不需要任何更改。
【解决方案2】:

首先,我们有时只在一个应用程序中部署了几个程序集,而不是整个应用程序。然而,这绝不是常态,并且仅在开发人员最近(如在过去几分钟内)发布整个站点并且只是进行微小调整时才在我们的测试环境中完成。但是,一旦开发人员感到满意,他们就会继续进行完整的重新编译和重新发布。

最后的测试总是基于完全重新编译/部署。对分期和最终生产的推动基于该完整副本。

除了可重复性之外,一个原因是您真的不能 100% 肯定人类在比较中没有遗漏某些东西。其次,部署 100 个程序集而不是 5 个程序集的时间是微不足道的,坦率地说,不值得花费大量时间来尝试找出真正发生的变化。

坦率地说,您所拥有的清单与 Oded 的回答相结合,应该足以让其他人相信失败的可能性。但是,由于这种懒散的方法,您已经遇到了失败,这一事实应该足以阻止它继续进行。

归根结底,这真的归结为一个专业问题。将代码从开发中移出、通过各种环节并最终进入生产过程的标准化和可重复性对于创建健壮的任务关键型应用程序极为重要。如果您的部署过程由于这些类型的风险导致捷径而充满失败的可能性,那么就会对正在生成的代码的质量提出质疑。

【讨论】:

  • 我可以直接复制粘贴你的答案,然后发给我的老板吗? :p
  • @Ray:当然。当然,问题是他/她会读吗?
猜你喜欢
  • 1970-01-01
  • 2012-04-25
  • 1970-01-01
  • 1970-01-01
  • 2016-09-28
  • 2018-09-20
  • 1970-01-01
  • 1970-01-01
  • 2017-08-02
相关资源
最近更新 更多