Où les parameters régionaux / culture du système sont-ils définis pour .Net?

J’ai un problème avec ac # assembly (.net 2.0 écrit à l’aide de Visual studio 2005) installé sur un serveur britannique et devant utiliser les parameters régionaux du Royaume-Uni.

Ce que mon code fait est de convertir une date sous la forme jj / mm / aaaa en utc. c’est-à-dire aaaa-mm-jj. Le problème est survenu avec des dates telles que 16/02/2010 où le composant n’a pas pu convertir la date et a renvoyé une erreur. Après le débogage, j’ai réalisé que, pour une raison étrange, CultureInfo renvoyé par System.CultureInfo est en-US.

Je peux modifier ces parameters par programmation en utilisant:

Thread.CurrentThread.CurrentCulture = new CultureInfo("en-GB", false);

et mon code fonctionne bien.

Cependant, je ne veux pas le faire tout le temps car mon système devrait être le Royaume-Uni. Pas nous. Alors, comment puis-je changer la culture par défaut pour .NET Framework soit par défaut en-GB au lieu de en-US?

Pour information:

J’ai essayé de mettre à jour le fichier machine.config et de spécifier culture = en-GB pour la section globalisation (elle était définie sur neutre), mais cela ne fonctionne pas non plus [je l’ai fait pour les versions 1.1 et 2.0] mais il est possible que je ne l’aie pas changé correctement.
J’ai vérifié mes parameters régionaux Windows et ils sont définitivement configurés au Royaume-Uni avec des dates telles que jj / mm / aaaa
J’exécute sur un serveur virtuel et j’ai vérifié mon système hôte. Il est également réglé au Royaume-Uni

Modifier:

Quelques détails supplémentaires sur le contexte. L’assembly en question est appelé via COM interop à partir d’un composant tiers C ++ natif qui s’exécute en tant qu’application COM +.

Il n’est pas nécessaire de modifier CurrentCulture pour effectuer la transformation. Si vous êtes certain que la date est sous la forme “jj / mm / aaaa”, vous pouvez utiliser

 DateTime dtTemp = DateTime.ParseExact(dateSsortingng, "dd/MM/yyyy", null) // in order not to have to specify a FormatProvider

et ensuite utiliser

 dtTemp.ToSsortingng("yyyy-MM-dd")

De cette façon, vous n’aurez pas de problème, peu importe ce qu’est la CurrentCulture. Toutefois, si vous n’êtes pas certain que la date a la forme “jj / mm / aaaa” et qu’elle est plutôt basée sur le format de date courte CurrentCulture, vous devez utiliser

 DateTime dtTemp = DateTime(dateSsortingng, CurrentCulture.DateTimeFormat.ShortDatePattern, CurrentCulture.DateTimeFormat);

Le serveur n’est pas configuré correctement. Panneau de configuration + Région et langue, onglet Emplacement. Changer cela pourrait être un peu délicat. Le serveur a peut-être été mal configuré express. Parlez à l’administrateur du serveur avant de faire quoi que ce soit.

Votre plan de secours consiste à utiliser la surcharge de méthode DateTime.TryParse () qui prend l’argument IFormatProvider. Passez CultureInfo.GetCultureInfo (“en-gb”). DateTimeFormat.

Hmmm, selon les documents de l’ API :

Lorsqu’un thread est démarré, sa culture est initialement déterminée à l’aide de GetUserDefaultLCID partir de l’API Windows.

Cette méthode dérive ses parameters régionaux des parameters régionaux par défaut de l’utilisateur (comme leur nom l’indique), ce qui, je suppose, se trouve dans le Panneau de configuration. Remarque : ce n’est pas le même que les parameters régionaux de l’interface utilisateur.

merci pour vos réponses (andy a posté la question en mon nom). Il s’agissait bien d’un problème avec les parameters régionaux, mais ni avec l’utilisateur auquel j’étais connecté, ni avec l’utilisateur sous lequel le processus s’exécutait. Cela aurait été trop facile. Il semble que l’utilisateur par défaut était toujours en-US. J’ai réinitialisé en cochant la case “Appliquer les parameters à l’utilisateur actuel et à l’utilisateur par défaut …” dans l’onglet Options avancées et en redémarrant le serveur. System.Globalization.CultureInfo renvoie maintenant {en-GB}. Et un MyDate.ToSsortingng (aaaa-mm-jj) fonctionne correctement, que la date soit passée en jj / MM / aaaa ou jj-MM-aaaa ou aaaa-MM-jj sans qu’il soit nécessaire d’parsingr.

Merci cependant à vous tous pour vos suggestions (ParseExact, etc.) qui ont effectivement fonctionné. Ils seront très utiles pour d’autres formats de date que je n’étais pas capable de gérer de manière agréable (aaaaMMj).

Marc

Je crois que cela est représenté par System.Globalization.CultureInfo.InstalledUICulture, donc si rien d’autre, vous pouvez peut-être copier cela dans la culture actuelle du fil. Je suis surpris que vous ayez trouvé un cas où la culture des threads est différente de la culture installée. Peut-être que votre code est en cours d’exécution dans un processus qui a changé la culture?

Il est possible que le compte qui exécute le code ait des parameters régionaux différents de ceux définis par défaut par le système. Avez-vous vérifié cela?

Pour définir la culture et la culture de l’interface utilisateur pour toutes les pages, ajoutez une section de globalisation au fichier Web.config, puis définissez les atsortingbuts d’uiculture et de culture, comme indiqué dans l’exemple suivant:

Les assemblages dans le cadre .net sont neutres en termes de culture.

Quel code essayez-vous de convertir la date? ~~Si vous utilisez Parse ou TryParse , essayez de fournir l’argument de la culture pour lui permettre de comprendre la date.~~