我正在设计一个 Visual Studio 项目，该项目可能会使用大量(最多约 300 个)各种类型的脚本文件。这些文件不会与其他项目共享，即它们是项目独有的。是否有任何好的理由反对将所有这些文件作为嵌入资源(通过设置它们的构建操作)然后使用Assembly.GetManifestResourceStream()在运行时检索它们？或者这是对嵌入式资源的误用，应该改用将这些资源作为文件保存的文件系统目录？
使用嵌入式资源的好处似乎是:
- 生成的程序集易于共享和部署(单文件部署，无需担心丢失脚本文件或无效路径)；
- 隔离和方便:所有资源都可以从 VS 项目中访问。
反对这种方法的论点通常是:
- 您不能在不重新编译和重新部署程序集的情况下修改资源。然而，即使对于具有许多基于文本的资源的项目，生成的程序集也将相当小并且与重写一样容易重新部署，例如一个位于文件系统的脚本文件将是。从理论上讲，应该可以只替换程序集的更改部分(因此更新较小)，但我不知道是否存在任何此类现有差异/合并工具。
- 生成的 DLL 会更大，最终可能会大得多；但是话又说回来，如果您创建了一个没有嵌入资源的精益程序集并将资源单独部署到一个目录，那么要部署的程序的总大小将是相同的。
还有其他注意事项吗？更一般地说，除了在修改的情况下所需的程序集重新编译之外，是否有理由不应将项目资源(无论它们是什么)作为嵌入式资源包括在内？
最佳答案
我可以从复杂的环境角度给你一些见解。
如果您的应用程序对您的组织来说几乎是关键的或重要的，并且您需要最大限度地减少事件响应时间，那么最好将所有脚本作为单独的文件。尽管重新编译您的程序集可能非常容易，但在结构化的公司环境中，即使在紧急情况下，修补程序发布通常也需要跳过许多环节。此外，这需要开发人员，而支持人员应该足以更改脚本文件。
其他考虑因素可能是(至少某些)脚本在从资源流式传输时是否无法正常运行。他们可能需要一个地方来写入中间数据或结果数据。脚本之间也可能存在一些依赖关系(一个调用另一个等)
另一个因素是，当您无权访问项目源代码时，将资源分开可以进行快速审查。这为您的应用程序增加了一些透明度(这可能是需要的，也可能不需要)。它还可能有助于确定您的应用程序在出现问题时发生了什么，并可能做出快速更改/修复(有点类似于我的第一点)。
通常我会说这取决于您的要求。如果您需要能够频繁更改脚本(或其他不可编译的资源)，那么将它们分开会更好。如果它们不经常更改并且您喜欢整洁、简单和紧凑的文件结构，那么嵌入是一个不错的选择。
关于c# - 将大量脚本作为嵌入式资源包含到项目中是一种不好的做法吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37986248/