哪些更改需要重新部署依赖程序集？

Question

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

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

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

还有其他我们遗失的案例吗？我也很同意为什么这整个方法都存在缺陷(虽然已经使用了多年).

编辑为了清楚起见,我们总是重新编译,但只是部署其中源文件已更改的程序集.

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

Answer 1

这是另一个:

对可选参数值的更改.

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

 public void MyOptMethod(int optInt = 5) {}

任何调用代码,例如:

 theClass.MyOptMethod();

将最终编译为:

 theClass.MyOptMethod(5);

如果将方法更改为:

 public void MyOptMethod(int optInt = 10) {}

如果要应用新的默认值,则需要重新编译所有相关的程序集.

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

所以 - 总是重新编译一切.

尼斯.特别危险,因为呼叫不会失败,它只会使用错误的值. (2认同)
对泛型类型参数,函数名称(甚至是私有,如果你使用Reflection),异常行为(即抛出x,y,z而不是x,y),线程安全性的更改以及一大堆其他的约束也会发生变化你应该总是重新编译的原因. (2认同)

Answer 2

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

测试的最终推动始终基于完整的重新编译/部署。演出和最终制作的推动都是基于完整的副本。

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

坦率地说，您所列出的清单与奥德的回答相结合应该足以让其他人相信失败的可能性。然而，由于这种懒散的方法，您已经遇到了失败，这一事实应该足以成为一个警告标志，阻止它继续下去。

归根结底，这实际上归结为专业精神的问题。将代码从开发中移出、经过各种环节并最终进入生产的过程的标准化和可重复性对于创建强大的关键任务应用程序极其重要。如果您的部署过程充满了由于这些类型的风险诱发捷径而导致失败的可能性，则会引发对所生成代码的质量的质疑。