3

我知道有几个关于卫星大会的问题，但是在尝试实施它们时我仍然遇到了一些麻烦

我的目标是在一个程序集中分离每种文化，让我可以灵活地在需要时一次只重新编译一个程序集，如果我只想对一种语言进行一些小的更改，我不想编译所有语言语

我想充分了解卫星大会的工作方式。这是我目前的理解：

  • 卫星程序集可以放在 bin 目录中，而无需重新编译整个应用程序，这意味着应用程序不需要这些程序集即可正常工作（只要指定了备用资源）

  • SA 必须与单一文化相关联

现在我可以使用该工具生成 SA al，如果我添加 .resx 文件，Visual Studio 可以为我生成 SA，SA 已创建（在 bin 文件夹中，我可以看到指定区域性的文件夹结构）

问题1.这些dll是不是等价的，一个是Visual Studio生成的，一个是al工具生成的？

问题 2.所有这些 dll 是否必须共享一个通用名称才能工作？（我知道他们应该保持一致性，但如果他们不共享名称，让我们说使用al指定不同名称的工具创建它们）它们仍然可以被要加载的.Net框架识别吗？

问题 3.如果我想使用ResourceManager该类，是否必须为每个装配文化实例化一个实例？（并且由于它们的名称中包含区域性，因此它们具有不同的程序集名称，我是否必须手动格式化嵌入的资源文件以加载以匹配当前区域性并手动加载该程序集？因为它们可能不会在第一次加载，我是否必须通过指定文化文件夹中的文件路径来手动加载它？）

问题 4.这些 SA 是由 .Net 框架自动加载的，还是我必须显式加载它们？

问题 5。如果我必须加载它们，这意味着如果我想在我的控制标签中以声明方式指定资源，我是否必须创建并注册一个自定义资源工厂才能加载它们？

问题 6.如果我在 Visual Studio 的一个类项目中添加多个文化的多个资源而没有代码，它们会自动嵌入，当我编译时，会创建每个文化的附属程序集，这些 dll 是否相关？我想知道它们是否按名称、名称空间或其他东西相关

所有这些问题都基于此：我认为我可以将程序集添加到 bin 文件夹并在ResourceManager. （这就是为什么我关心程序集名称或几个附属程序集是如何相关的）就像在单个程序集中定义资源时一样，您只需Resources.MyResourceKey调用

我很感激你的帮助，这个话题让我发疯了=（

4

1 回答 1

3

我知道resgen和al工具看起来比它们应该的要复杂一些，但我很确定您的目标是可以实现的，即您可以在 Visual Studio 解决方案之外构建您的附属程序集（以节省您维护所有已翻译的解决方案中的资源），但得到完全相同的结果。

问题 1：是的

问题2：是的，ResourceManager 依赖命名约定来加载本地化资源

问题 3：不可以。您可以使用标准的 ResourceManager。事实上，您根本不必直接使用 ResourceManager。在您的解决方案中包含您的基础资源并使用 Build Action = Embedded Resource 和 Custom Tool = PublicResXFileCodeGenerator 对其进行配置，然后 Visual Studio 将自动生成和维护一个类（与您的 resx 文件同名），该类允许您通过静态属性访问资源. 根据 Thread.CurrentThread.CurrentUICulture 和部署的附属程序集，这些属性将为您提供来自附属程序集或基础程序集的本地化资源。

问题 4：不。ResourceManager 会自动执行此操作。

问题 5：见 Q4。没事做。

问题 6：见 Q2。它基于命名约定（根据文化命名的文件夹，根据基本 dll 命名的附属程序集）和元数据（例如，使用 al 编译时使用的文化名称）

于 2012-06-19T11:06:18.107 回答