asp.net - 隐式本地化、强类型资源、App_LocalResources 和嵌入式资源

Question

tl;博士强类型资源代码生成是否适用于 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 中的文件?

请注意，尝试执行此操作时抛出的异常是 System.Resources.MissingManifestResourceException包含以下消息:

Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "PROJECT.App_LocalResources.PAGE.aspx.resources" was correctly embedded or linked into assembly "PROJECT" at compile time, or that all the satellite assemblies required are loadable and fully signed.

我知道此消息具有误导性，因为它清楚地查找附属程序集而不是尝试 resx文件(或运行时编译成的任何文件， App_LocalResources.dll 我猜)。

如果有充分的理由不允许这样做(因此我们被迫在附属程序集中使用嵌入式资源)，在进行隐式本​​地化时，是否有可以在附属程序集中查找资源的资源提供程序的良好实现？ 以前肯定有人尝试过这样做，但解决这种管道问题听起来不像是应用程序开发人员的工作。

作为前一个问题的子问题，我还假设在附属程序集中使用嵌入式资源时，不会将 resx App_* 中的文件目录，因为这些是运行时使用的特殊目录。确实，resx文件甚至没有部署，所以目录是空的。这是正确的吗？关于这方面的最佳实践有什么可以通过的？

我想提出问题的另一种方式是:我可以制作 ResXFileCodeGenerator吗？表现得像 GlobalResourceProxyGenerator在生成可以加载运行时编译的程序集的代码时，而不是在构建时编译的附属程序集？

Answer 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/

我不建议将 Resource Provider 中的 App_ 文件夹资源与强类型资源混合使用，因为您最终会使用不同的机制加载两组不同的资源。它有效并且可以完成，但它并不是很不一致。选择一种方法或另一种方法。对于 Web 窗体，资源提供者模型工作得更好，因为它是您能够使用隐式资源的唯一方式。

请注意，ASP.NET MVC 通常不使用 ASP.NET 资源提供程序(尽管可以)，而是依赖嵌入到代码中的强类型资源。如果您的 WebForms 代码主要是基于脚本的，那么使用嵌入式资源可能会很好，但如果您需要绑定(bind)控件属性，则资源提供程序是唯一的方法。