为什么没有针对.NET框架的私有部署选项？

Question

以下是我们需要这样做的原因: 1)我们通常不使用所有的dll，但我们强迫客户安装整个.NET框架。只要部署我们需要的dll就好了。

2)我们通常希望更新我们的应用程序和框架，但有时需要重新启动机器，因为其他应用程序都在使用它。

3)一个完整的.NET安装通常需要相当长的时间。xcopy私有部署可能要快得多。

在我看来，mono允许私有部署来解决所有这些问题。

谢谢

Answer 1

MS不喜欢这个模型有一个简单的原因--如果任何程序包含自己版本的.NET框架DLL，Windows将无法有效地为.NET框架DLL提供任何安全更新/ bug修复。这不是一个假设的问题:过去每隔几个月，MS就会为框架DLL部署一个新的补丁或安全更新。

MS将特定的运行时DLL分配给应用程序供应商，并让供应商自己负责部署和更新DLL的情况并不是新的情况。例如，MFC、GDI+ DLL和其他一些库通常都是以这种方式部署的。但是，这几乎总是导致用户在获得这些DLL的重要更新方面遇到困难。例如，请参见这里，从2004年起，gdiplus.dll必须更新--与使用"Windows“机制进行相对完美的更新相比，这对用户意味着什么麻烦。从这段经历中，我猜MS得出的结论是，不让他们承担更新的责任。

对于你们的论点：

1)我们通常不使用所有的all，但我们强迫客户安装整个.NET框架。只要部署我们需要的dll就好了。

更新的Windows版本已经包含了.NET FW3.5或4.0，如果没有，框架必须在每台机器上安装一次(ok，3.5一次和4.0一次)，而不是一次又一次地安装每个需要它的应用程序。

2)我们通常希望更新我们的应用程序和框架，但有时需要重新启动机器，因为其他应用程序都在使用它。

您通常不想自己更新框架，Windows为您做了这些工作。如果您要使用到目前为止还没有安装在机器上的新框架版本，那么到目前为止，显然不可能有另一个应用程序使用新的框架。

3)一个完整的.NET安装通常需要相当长的时间。xcopy私有部署可能要快得多。

是的，但每台机器只有一次，而不是每个应用程序一次。

@BryantB的回答也是正确的。特别是，因为.NET程序集的执行模型不检查是否在JITer编译对其中一个程序集的函数调用之前安装了所有所需的程序集。这意味着，如果您忘记部署框架DLL，您的程序可能会完美无缺地启动，但是当使用第一个需要忘记的DLL的特性时，程序可能会崩溃。这种行为与本地DLL(当然不是延迟加载的DLL)有很大的不同，而且会是一个危险的错误陷阱。

Answer 2

我可以想到的一件事是，如果安装了整个框架，.NET应用程序就存在一致的环境。这并不是说大多数开发人员无法确定哪些.NET程序集必须存在于私有部署场景中。但是，安装框架可以保证.NET应用程序至少会成功启动。