tl;dr在App_LocalResources
中使用正常(非嵌入式)资源进行强类型资源代码生成。
如果不是,为什么,以及在卫星程序集中使用嵌入式资源的替代方法是否与隐式本地化工作?
这篇文章的其余部分只是解释了我目前在解决这些问题时所处的位置,如果你知道答案的话,可以随意忽略它。
当使用隐式本地化(meta:resourceKey="Foo"
语法)时,我理解如果要将资源嵌入到附属程序集中,就需要编写自己的资源提供程序。原因可能是这些文件的ASP.NET always uses the default provider,而且该提供程序希望在运行时可以检索App_LocalResources
中的resx
文件。请参见this question,它在撰写本文时没有答案。
如果这个假设是正确的,那么如果不编写这样的提供程序(我们希望避免这样做),就不可能使用强类型生成的类(使用ResXFileCodeGenerator
),因为启用代码生成需要使用嵌入式资源。
由于生成类型的使用对于全局资源似乎非常有效,我想对第二个假设提出质疑:
App_GlobalResources
中使用GlobalResourceProxyGenerator
),而不将它们嵌入到附属程序集中(Build Action
设置为Content
,而不是Embedded
),那么为什么不能对本地资源执行相同的操作呢?,为什么生成的代码不能在App_LocalResources
中查找和使用resx
文件?请注意,尝试执行此操作时引发的异常是包含以下消息的System.Resources.MissingManifestResourceException
:
找不到适合指定区域性或中性区域性的任何资源。确保"PROJECT.App_LocalResources.PAGE.aspx.resources“在编译时正确嵌入或链接到程序集”项目“,或者确保所需的所有附属程序集都是可加载和完全签名的。
我知道这条消息是误导的,因为它明显地查找附属程序集,而不是尝试resx
文件(或者运行时编译到的任何东西,我猜是App_LocalResources.dll
)。
resx
文件放在App_*
目录中,因为这些是运行时使用的特殊目录。实际上,resx
文件甚至没有被部署,所以目录将是空的。这是正确的吗?在这方面有什么最佳做法吗?我认为另一种表述问题的方法是:在生成能够加载运行时编译的程序集的代码时,我是否可以让ResXFileCodeGenerator
像GlobalResourceProxyGenerator
一样运行,而不是在构建时编译的附属程序集?
发布于 2014-09-26 09:47:38
嵌入式资源可以与驻留在App_LocalResources/App_GlobalResources文件夹中的ASP.NET资源提供程序资源共存。但是,所有内部WebForms本地化功能都只使用由ASP.NET资源提供程序提供的资源,这意味着默认情况下,资源仅来自App_文件夹-而不是来自嵌入式资源。
嵌入式强类型资源不使用ASP.NET资源提供程序--它们使用股票.NET资源管理器,当您使用它们时,ASP.NET ResourceProvider系统在vis缓存和资源加载中使用的一些优化会丢失。在ASP.NET场景中,它更有效。
正如您正确地指出的那样,可以通过创建一个自定义资源提供程序来读取嵌入式资源(或来自另一个源(如数据库)的资源),但是您必须创建这个资源提供程序并将其连接起来。我在不久前的一篇文章(使用SQL数据库提供程序)中写到了这一点:http://www.west-wind.com/presentations/wwDbResourceProvider/
我不建议将来自resources的App_文件夹资源与强类型资源混合使用,因为您最终将使用不同的机制加载两组不同的资源。这是可行的,也是可以做到的,但并不是很不一致。选择一种或另一种方法。对于Web表单,资源提供者模型工作得更好,因为这是您能够使用隐式资源的唯一方式。
请注意,ASP.NET MVC通常不使用ASP.NET资源提供者(尽管可以),而是依赖嵌入到代码中的强类型资源。如果您的WebForms代码主要是基于脚本的,那么使用嵌入式资源可能会很好,但是如果您需要绑定控制属性,那么Resource是唯一可行的方法。
https://stackoverflow.com/questions/24413709
复制相似问题