tne*_*tne 7 asp.net localization webforms embedded-resource
tl; dr强类型资源代码生成是否适用于普通(非嵌入)资源App_LocalResources？
如果不是那么为什么,并且在卫星装配中使用嵌入资源的替代方案是否可以与隐式本地化一起使
本文的其余部分只是解释了我目前在解决这些问题的位置,如果您知道答案,请随时忽略它.
当使用隐式本地化(meta:resourceKey="Foo"语法)时,我理解如果想要将资源嵌入到附属程序集中,则需要编写自己的资源提供程序.原因是ASP.NET总是使用这些的默认提供程序,并且此提供程序期望可以在运行时检索其中的resx文件App_LocalResources.另见这个问题,在撰写本文时尚无答案.
如果这个假设是正确的,那么在ResXFileCodeGenerator没有编写这样的提供者(我们希望避免这样做)的情况下似乎不可能使用强类型生成的类(使用),因为启用代码生成需要使用嵌入式资源.
因为生成类型的使用似乎对全局资源完全正常,所以我想质疑第二个假设:
App_GlobalResources使用中GlobalResourceProxyGenerator)生成强类型类而不将它们嵌入到附属程序Build Action集中(设置Content为相反Embedded),那么为什么我不能对本地资源执行相同操作？ 为什么生成的代码无法找到并使用这些resx文件App_LocalResources？请注意,尝试执行此操作时抛出的异常System.Resources.MissingManifestResourceException包含以下消息:
找不到适合指定文化或中性文化的资源.确保在编译时将"PROJECT.App_LocalResources.PAGE.aspx.resources"正确嵌入或链接到程序集"PROJECT"中,或者所有所需的附属程序集都是可加载和完全签名的.
我知道这条消息具有误导性,因为它清楚地查找了附属程序集,而不是尝试resx文件(或者运行时编译的任何内容,App_LocalResources.dll我猜).
如果有充分的理由不允许这样做(并且我们因此被迫在卫星装配中使用嵌入式资源),那么在进行隐式本地化时是否可以在资源提供程序中查找资源？ 当然有人曾试图这样做,并且听起来不像应用程序开发人员的工作来解决这种管道问题.
作为前一个问题的一个子问题,我还假设在卫星程序集中使用嵌入式资源时,不会将resx文件放在App_*目录中,因为这些是运行时使用的特殊目录.实际上,resx文件甚至没有部署,因此目录将为空.这是正确的,有什么可以通过作为最佳做法？
我想另一种制定问题的方法是:我是否可以ResXFileCodeGenerator像GlobalResourceProxyGenerator生成可以加载运行时编译的程序集的代码那样表现,而不是在构建时编译的附属程序集？
嵌入式资源可以与位于 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 代码主要基于脚本，那么使用嵌入式资源可能效果很好，但如果您需要绑定控件属性，则资源提供程序是唯一的方法。