背景
一期工程安装包含的所有元素来定义一个用户控件的一些文件 - 一些用户来源，设计师代码CodeCompileUnit和RESX文件。 在运行时，这些文件被编译成一个组件和类是我们主要的应用程序所消耗（大会只更新需要时提供）。
题
该项目已被全球化和作为这一过程的一部分，有必要提供这些文件的本地化。 两个选项是要么允许包含用于不同的区域设置附加RESX文件可被编译为一个卫星组件，用于主组件（无论是相同的文件或作为其他的侧面通过侧文件内），或者提供的副本被支持的每一个完整文件支持的每种语言，一种编译语言的相应集。
- 有没有人有可能是值得考虑任何其他的选择吗？
- 有什么问题可以在任我提出的解决方案的内在？
约束/免责声明
我知道的情况是不太理想的，并且更好的选择可能在某些领域已经取得（如从一开始全球化），但他们不能在项目的这点改变。 我明白任何意见，解决方案，或导致您可以提供。 谢谢。
为每个培养物的单独的卫星组件。 这有两个好处：
- 你可以建立所有组件中一气呵成，并为每个版本号和文件名组合一个明确的文件，而不是它也取决于文化。
- 你可以有多个组件在相同的安装，以及基地的系统语言使用的语言，或用户偏好等，这将使开发和测试显著更容易，因为你不会需要不断改造和复制文件只左右改变语言的缘故。
- 这是.NET国际化是如何设计工作。 虽然我不是.NET国际化的专家（“读盖伊·史密斯，费里尔的书”是我最好的建议！）我发现一般框架的工作时，你最好按照他们的预期模型。
即使“建设卫星集结号”的最后一部分是在运行时完成（你可以做到这一点，在安装的时候呢？），你仍然至少获得第二和第三颗子弹的优势。 这也意味着，去提供卫星组件的比较正常的途径，如果你做的开始（而不是建立他们对用户的箱体）配合你可以少改变。
道歉，如果我误解了这个问题，但...
如果你没有在部署后添加更多的语言（至少在没有软件更新）计划，那么我会赞成编译所有的附加文件RESX到您包括卫星组装。 这样一来，他们不是用户可编辑一旦他们部署。
