Question

在我的工作场所，我们只更换已更改的程序集（不是我的想法）来部署内部应用程序。

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

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

我们还缺少其他任何案件吗？我也赞成为什么这整个方法存在缺陷（虽然已经使用了多年）。

编辑为了清楚起见，我们一直在重新编译，但只是部署其中源文件发生变化的程序集。

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

Answer 1

这是另一个：

可选参数值的更改。

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

 public void MyOptMethod(int optInt = 5) {}

任何调用代码，例如：

 theClass.MyOptMethod();

最终会编译为：

 theClass.MyOptMethod(5);

如果您将方法更改为：

 public void MyOptMethod(int optInt = 10) {}

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

需要重新编译的其他更改（感谢多项式）：

所以 - 始终重新编译一切。

Answer 2

首先，我们有时只在应用程序中部署了几个程序集而不是完整的应用程序。然而，这绝不是常态，并且只有在开发人员最近（如在最近几分钟内）发布整个站点并且只是进行了一些小调整时，我们的测试环境中才进行此操作。但是，一旦开发人员满意，他们就会继续进行完全重新编译并重新发布。

最后的测试总是基于完整的重新编译/部署。推送到分期并最终生产是基于完整副本。

除了可重复性之外，一个原因是你真的不能100％肯定人类在比较中没有错过任何东西。接下来，部署100个组件与5个组件的时间是微不足道的，坦率地说，不值得花费时间来尝试找出真正改变的东西。

坦率地说，你与Oded的答案相结合的名单应该足以让别人相信失败的可能性。但是，由于这种缺乏实际的方法，你已经遇到了失败的事实应该足以成为警告标志，以阻止它继续下去。

在一天结束时，它真的归结为专业性问题。将代码移出开发，通过各种环节并最终投入生产的过程的标准化和可重复性对于创建强大的关键任务应用程序非常重要。如果您的部署过程因为这些类型的风险导致捷径而可能导致失败，那么就会对所生成代码的质量提出质疑。