全球化运行时生成的程序集

Question

背景

项目安装一些文件，其中包含用于定义UserControl的所有元素 - 一些用户源，一个用于设计器代码的CodeCompileUnit和一个resx文件。在运行时，这些文件被编译成一个程序集，这些类由我们的主应用程序使用（程序集仅在必要时更新）。

问题

项目必须全球化，并且作为该过程的一部分，需要提供这些文件的本地化。有两个选项可以允许为不同的语言环境（在相同的文件中或作为附加的并排文件）包含额外的resx文件，这些文件可以编译到主程序集的附属程序集中，或者提供副本每种受支持语言的每个完整文件，为所支持的语言编译适当的集合。

• 有没有人可能值得考虑其他选择？
• 我提出的任何一种解决方案都可能存在哪些问题？

---

约束/免责声明
我知道这种情况不太理想，并且可以在某些领域做出更好的选择（比如从一开始就全球化），但是在项目的这一点上它们无法改变。我感谢您提供的任何建议，解决方案或潜在客户。感谢。

Answer 1

为每种文化创建单独的附属程序集。这有两个好处：

• 您可以一次性构建所有程序集，并为每个版本号和文件名组合创建一个确定的文件，而不是也，具体取决于文化。
• 您可以在同一个安装中拥有多个程序集，并根据系统语言或用户首选项等使用该语言。这将使开发和测试变得更加容易，因为您不需要继续重建和复制文件周围只是为了改变语言。
• 这就是.NET i18n的设计方式。虽然我不是.NET i18n的专家（“阅读Guy Smith-Ferrier的书”是我最好的建议！）我通常发现当你遵循他们期望的模型时，框架效果最好。

即使“构建附属装配”的最后部分是在运行时完成的（你可以在安装时间吗？），你仍然至少可以获得第二和第三个子弹的优点。这也意味着，如果你曾经做去提供卫星装配开始的更正常的路线（而不是在用户的盒子上建造它们），你将有更少的改变。

如果我误解了这个问题，我会道歉......

Answer 2

如果您不打算在部署之后添加其他语言（至少没有软件更新），那么我倾向于将所有其他RESX文件编译为您包含的附属程序集。这样，一旦部署，用户就无法编辑。