tl; dr 强类型资源代码生成是否适用于App_LocalResources中的普通（非嵌入）资源？
如果不是那么为什么，并且在卫星装配中使用嵌入资源的替代方法是否可以使用隐式本地化？
本文的其余部分只是解释了我目前在解决这些问题的位置，如果您知道答案，请随时忽略它。
当使用隐式本地化（meta:resourceKey="Foo"语法）时，我理解如果想要将资源嵌入到附属程序集中，则需要编写自己的资源提供程序。原因是ASP.NET always uses the default provider对于这些，并且此提供程序期望resx中的App_LocalResources文件可以在运行时检索。另请参阅撰写本文时没有答案的this question。
如果这个假设是正确的，那么在没有编写这样的提供者的情况下，似乎不可能使用强类型生成的类（使用ResXFileCodeGenerator）（我们希望避免使用（），因为启用代码生成需要使用嵌入式资源。
因为使用生成的类型似乎对全局资源完全正常，我想质疑第二个假设：
App_GlobalResources中使用GlobalResourceProxyGenerator）而不将它们嵌入到附属程序集中（Build Action设置为Content而不是Embedded resx），然后为什么我不能对本地资源执行相同操作？为什么生成的代码无法在{中查找和使用App_LocalResources文件{1}}？请注意，尝试执行此操作时抛出的异常是包含以下消息的System.Resources.MissingManifestResourceException：
无法找到适合指定文化的任何资源或 中性文化。确保 ＆＃34; PROJECT.App_LocalResources.PAGE.aspx.resources＆＃34;是 正确嵌入或链接到汇编＆＃34; PROJECT＆＃34;在 编译时间，或所需的所有附属程序集 可加载和完全签名。
我知道这条消息具有误导性，因为它清楚地查找了附属程序集，而不是尝试resx文件（或运行时编译的任何文件，我猜App_LocalResources.dll）
如果有充分的理由不允许这样做（我们因此被迫在附属程序集中使用嵌入式资源），是否可以在资源提供程序中查找资源隐式本地化时的卫星装配？以前有人试图这样做，并且它听起来不像应用程序开发人员那样解决这种管道问题。
< / LI>作为前一个问题的子问题，我还假设在卫星装配中使用嵌入资源时，不会将resx文件放在App_*目录中，因为这些是运行时使用的特殊目录。实际上，resx文件甚至没有部署，因此目录将为空。这是否正确，是否有关于此的最佳做法？
我想另一种制定问题的方法是：在生成可以加载运行时编译的程序集的代码时，我可以使ResXFileCodeGenerator的行为类似于GlobalResourceProxyGenerator，而不是编译的卫星程序集。建立时间？
答案 0 :(得分：1)
嵌入式资源可以与位于App_LocalResources / App_GlobalResources文件夹中的ASP.NET资源提供程序资源共存。但是所有内在的WebForms本地化功能仅适用于ASP.NET资源提供程序提供的资源，这意味着默认情况下资源仅来自App_文件夹 - 而不是来自嵌入式资源。
嵌入式强类型资源不使用ASP.NET资源提供程序 - 它们使用库存.NET资源管理器，当您使用它们时，会丢失ASP.NET ResourceProvider系统使用的一些优化，以及缓存和加载资源。它在ASP.NET场景中更有效。
正如您正确指出的那样，可以通过创建读取嵌入资源（或来自其他来源（如数据库）的资源）的自定义资源提供程序来实现此目的，但您必须创建此资源提供程序并将其挂起。我在前一篇文章（使用SQL数据库提供程序）中写过这篇文章：http://www.west-wind.com/presentations/wwDbResourceProvider/
我不建议将资源提供程序中的App_文件夹资源与强类型资源混合，因为最终会使用不同的机制加载两组不同的资源。它可以工作并且可以完成，但它不是很不一致。选择一种方法或另一种方法。对于Web窗体，资源提供程序模型更好地工作，因为它是您能够使用隐式资源的唯一方法。
请注意，ASP.NET MVC通常不会使用ASP.NET资源提供程序（尽管可能），而是依赖于嵌入到代码中的强类型资源。如果您的WebForms代码主要基于脚本，那么使用嵌入式资源可能会运行良好，但如果您需要绑定控件属性，则资源提供程序是唯一的方法。