Définir la culture pour l'ensemble de l'appdomain

Question

Je crée un service Windows qui exécute plusieurs threads. Puis-je définir la culture de l'intégralité de mon appDomain, au lieu de le définir séparément pour chaque thread?

Answer 1

Ce n'est pas possible. Les threads obtiennent leur culture par défaut lorsque Windows crée le thread, initialisé à partir des paramètres régionaux par défaut du système, comme configuré dans Panneau de configuration + Région et langue. Les fonctions pertinentes de l'API Win32 sont Get/SetThreadLocale().

Il n'y a aucun mécanisme dans le CLR pour imbiber un thread avec un autre défaut. Un scénario courant pour un thread est de démarrer la vie créée par du code non géré et d'exécuter beaucoup de ce code non géré, en effectuant parfois un rappel dans le code managé. Ce code géré s'exécutera avec le jeu Thread.CurrentCulture sur la culture sélectionnée par le code non managé. Ou la valeur par défaut de Windows si le code non géré n'a pas appelé SetThreadLocale(). Avoir le CLR changer cela causerait l'échec non-diagnosticable dans le code non managé.

Bien sûr, vous pouvez le remplacer explicitement, mais c'est difficile à obtenir. Les erreurs de formatage subtiles sont assez faciles à voir, cela devient difficile quand vous utilisez, disons, des structures de données qui s'appuient implicitement sur les ordres de chaîne de compilation. Une liste SortedList ne peut soudainement pas retrouver un élément dans la liste réellement présente. Contrôler c'est difficile aussi, beaucoup de petits rappels thread threadpool dans tout le framework .NET. Ne pas déranger avec cela pour éviter de tomber dans des pièges comme ceux-ci, soit s'appuyer sur la valeur par défaut du système ou appliquer le CultureInfo explicitement.

---

MISE À JOUR: comme l'a noté Thomas, une solution sera disponible en 4.5 .NET, il a une nouvelle propriété pour la classe CultureInfo pour définir la culture par défaut du appdomain. Docs MSDN are here. L'interaction exacte avec les threads non gérés qui entrent dans le code managé n'est pas très claire dans la documentation, assurez-vous de vérifier cela si vous autorisez le code natif à effectuer des rappels, par exemple via pinvoke, Marshal.GetFunctionPointerForDelegate() ou un événement COM.

---

MAJ2: cela a été changé à nouveau dans .NET 4.6, la culture coule maintenant d'un fil à l'autre de sorte que les plus méchants modes de défaillance sont pris en charge. Lisez les détails à ce sujet dans l'article MSDN pour CultureInfo.CurrentCulture. Vous devez cibler explicitement 4.6 pour obtenir le bénéfice.

Answer 2

Vous pourriez avoir une méthode personnalisée qui déclenche les discussions et la culture définit automatiquement:

static bool StartThread(WaitCallback callback, object state) 
{ 
    return ThreadPool.QueueUserWorkItem(s => 
    { 
     // Set the culture 
     Thread.CurrentThread.CurrentCulture = new CultureInfo("es-ES"); 
     // invoke the callback 
     callback(s); 
    }, state); 
} 

Et quand vous avez besoin pour démarrer un nouveau thread il suffit d'utiliser cette méthode:

StartThread(state => { /** Do some processing on a new thread **/ }, null); 

Answer 3

Pour 4,5 cultures par défaut application de domaine pourrait être réglé par CultureInfo classe:

• DefaultThreadCurrentCulture
• DefaultThreadCurrentUICulture