Globalisation des assemblys générés à l'exécution

Question

Arrière-plan

Un projet installe des fichiers contenant tous les éléments permettant de définir un UserControl - une source d’utilisateurs, un CodeCompileUnit pour le code du concepteur et un fichier resx. Au moment de l'exécution, ces fichiers sont compilés dans un assemblage et les classes sont utilisées par notre application principale (l'assembly est mis à jour uniquement lorsque cela est nécessaire).

Question

Le projet doit être globalisé et, dans le cadre de ce processus, il est nécessaire de fournir des localisations de ces fichiers. Deux options permettent soit d’autoriser l’inclusion de fichiers resx supplémentaires pour différents paramètres régionaux (soit dans les mêmes fichiers, soit en tant que fichiers côte à côte supplémentaires) pouvant être compilés dans un assemblage satellite pour l’assemblage principal, soit de fournir une copie du fichier. chaque fichier complet pour chaque langue prise en charge, en compilant le jeu approprié pour la langue prise en charge.

• Quelqu'un a-t-il d'autres options à considérer?
• Quels problèmes pourraient être inhérents à l'une ou l'autre des solutions que j'ai proposées?

Contraintes / Avertissement
Je suis conscient que le scénario est loin d'être idéal et que de meilleurs choix auraient pu être faits dans certains domaines (comme la globalisation dès le début), mais ils ne peuvent pas être modifiés à ce stade du projet. J'apprécie tous les conseils, solutions ou pistes que vous pouvez fournir. Merci.

Answer 1

Créez un assemblage satellite distinct pour chaque culture. Cela présente deux avantages:

• Vous pouvez créer tous les assemblages en une fois et créer un fichier définitif pour chaque combinaison de numéro de version et de nom de fichier plutôt que également en fonction de la culture.
• Vous pouvez avoir plusieurs assemblys dans la même installation et baser la langue à utiliser sur la langue du système, sur une préférence utilisateur, etc. Cela facilitera considérablement le développement et les tests, car vous n'aurez pas besoin de reconstruire ni de copier. fichiers autour juste pour changer de langue.
• C’est ainsi que .NET i18n est conçu pour fonctionner. Bien que je ne sois pas un expert de .NET i18n ("lisez le livre de Guy Smith-Ferrier", c’est mon meilleur conseil!), Je trouve généralement que les cadres fonctionnent mieux lorsque vous suivez leur modèle.

Même si la dernière partie de "Construction de l'assemblage satellite" est fait à l'exécution (pouvez-vous le faire à installer au lieu de cela?), vous bénéficiez toujours des avantages de la deuxième et de la troisième puce au moins. Cela signifie également que si vous utilisez toujours plus l'habitude de fournir les assemblys satellites (au lieu de les construire sur la boîte de l'utilisateur), vous aurez moins de choses à changer.

Toutes mes excuses si j'ai mal compris la question ...

Answer 2

Si vous ne prévoyez pas l'ajout de langues supplémentaires après le déploiement (du moins pas sans mise à jour logicielle), je préférerais alors compiler tous les fichiers RESX supplémentaires dans un assemblage satellite que vous incluez. De cette façon, ils ne sont pas modifiables par l'utilisateur une fois qu'ils sont déployés.