将大量脚本作为嵌入式资源包含在项目中是不是一种不好的做法？

Question

我正在设计一个Visual Studio项目，它将使用各种类型的潜在大量（最多约300个）脚本文件。这些文件不会与其他项目共享，即它们是项目专有的。是否有任何好的论据反对将所有这些文件包含为嵌入式资源（通过设置其构建操作），然后使用Assembly.GetManifestResourceStream()在运行时检索它们？或者这是否会误用嵌入式资源，而应该使用将这些资源作为文件保存的文件系统目录？

使用嵌入式资源的好处似乎是：

• 生成的程序集易于共享和部署（单个文件部署，无需担心丢失脚本文件或无效路径）;
• 隔离和便利：可以从VS项目中访问所有资源。

反对这种方法的论据通常是：

• 您无法在不重新编译和重新部署程序集的情况下修改资源。但是，即使对于具有许多基于文本的资源的项目，生成的程序集也会相当小，并且像重写一样容易重新部署。一个位于文件系统的脚本文件。理论上，应该可以只更换程序集的更改部分（因此更小的更新），但我不知道是否存在任何此类现有的差异/合并工具。
• 生成的DLL会更大，最终可能会显着增加;但是，如果您创建了没有嵌入资源的精简装配，并且将资源单独部署到目录，那么要部署的程序的总大小将是相同的。

还有其他考虑因素吗？更一般地说，是否有一个原因是项目资源 - 不管它们是什么 - 不应该作为嵌入资源包括在内，除了在修改时需要的程序集重新编译？

Answer 1

我可以从复杂的环境角度给你一些见解。

如果您的应用程序对您的组织而言至关重要或重要，并且您需要最小化事件响应时间，那么将所有脚本作为单独的文件当然更好。尽管重新编译程序集可能非常容易，但在结构化企业环境中，即使在紧急情况下，修补程序版本通常也需要大量的环节才能完成。此外，这需要开发人员，而支持人员应该足以更改脚本文件。

其他考虑因素可能是（如果（至少某些）脚本在从资源流式传输时无法正常运行）。他们可能需要一个地方来编写中间数据或结果数据。脚本之间可能还存在一些依赖关系（一个调用另一个等）。

另一个因素是，当您无权访问项目源时，将资源分开可以快速查看。这为您的应用程序增加了一些透明度（可能需要或不需要）。如果出现问题，可能有助于确定应用程序发生的情况，并可能进行快速更改/修复（有点类似于我的第一点）。

一般来说，我会说这取决于您的要求。如果您需要能够频繁更改脚本（或其他不可编译的资源），那么将它们分开会更好。如果它们不经常更改并且您希望具有整洁，简单和紧凑的文件结构，那么嵌入是一个不错的选择。

Answer 2

如果这是一个仅在您自己的主机上使用的Web项目，那么最好不要将其用作嵌入式资源，而应用作常用文件。 （您只需要安装一次项目，但很容易进行小更新）

如果你想创建一个可以在其他项目中重用的dll，那么最好使用嵌入式资源 - 如果你做了一些更新，你可以在每个项目中只更新一个dll。