La mondialisation utilise incorrectement la culture par défaut dans tous les scénarios après le déploiement

Question

Environnement local:
Win10 x64
VS 2015 Mise à jour Pro 3
IIS 10.0 express

Environnement Production:
Win Server 2012 R2
IIS 8.5

Je suis en train de développer une application ASP.NET 4.6.1 MVC qui doit être prise en charge en anglais, danois et néerlandais. Je mets en œuvre les cultures neutres comme étant uniquement intéressé par la langue et non par les spécificités. J'utilise des assemblys satellites (comme certains les appelleraient) ou plutôt des fichiers Resource.resx pour mes traductions. Première approche j'ai suivi this often referenced post et cela fonctionne parfaitement localement. Dès que je le déploie dans l'environnement de production, les traductions cessent de fonctionner. Je définis les threads en fonction des valeurs de base de données: Et j'ai vérifié que cette méthode est toujours correctement exécutée dans l'environnement de production. J'ai essayé de régler les threads comme dans le post référencé qui fonctionne aussi bien localement, mais pas en production. Et j'ai même essayé de le mettre directement en haut de mon point de vue en utilisant le rasoir en vain. Ce qui me semble vraiment étrange, c'est que je l'ai fait travailler une fois dans l'environnement de production après avoir joué du violon, mais je suis presque sûr que je n'ai rien fait et tout à coup ça a marché. Malheureusement, il a cessé de fonctionner après avoir déployé une mise à jour de l'application, et je n'ai pas réussi à le faire fonctionner depuis. Je l'ai depuis essayé de jouer avec tous les paramètres dans l'environnement .NET sur IIS pour ce site et pour le répertoire racine:
Mais même spécification da-DK ou da que la culture ici ou directement dans le web .config de mon application ou codage en dur le fil à utiliser da comme la culture n'aide pas du tout. Ce qui est amusant, c'est que le formatage du nombre et de la date change correctement. Cela ne semble donc pas être un problème avec le thread n'ayant pas changé de culture, mais IIS refusant d'utiliser les autres fichiers de ressources. Lorsque déployé la structure de dossier a le dossier da dans bin et il contient un fichier nommé Resources.resources.resx qui je crois est correct. J'ai essayé d'avoir les fichiers de ressources situés dans une bibliothèque de classes comme le suggère l'article, mais aussi dans un dossier du même projet par frustration. Les fichiers de ressources sont définis sur l'accessibilité publique et sont compilés en tant que ressources intégrées sans copier les fichiers. Donc, ma question est, comment IIS refuse d'utiliser un autre fichier de ressources que le fichier par défaut? Et comment est-il possible que cela a fonctionné une fois? À ce stade, je ne considère que de prendre des traductions dans la base de données, car au moins cela fonctionne. Quelles suggestions avez-vous? Je crois que l'environnement .NET sur IIS a toutes les langues nécessaires installées car elles sont visibles dans les paramètres de globalisation .NET, mais je peux me tromper?

Mise à jour: J'ai essayé comme suggéré par NightOwl, encore une fois il fonctionne localement (débogage VS) et même si j'héberge les fichiers déployés dans iisexpress sur ma machine. Mais il échoue toujours sur l'environnement de production. La méthode proposée est similaire à this mais toujours sans succès. Je commence à penser que la solution consiste à passer à iis 10 dans l'environnement de production.

Answer 1

Le problème a été provoqué par le paquet Nuget SimpleImpersonation, qui semble changer la culture du thread courant dans les coulisses. Il semble que cela change à la valeur par défaut après qu'il a été éliminé, mais comme je mettais la culture pendant que la référence était valide, elle revenait toujours à en-US. Il est encore étrange que cela a fonctionné localement dans IIS Express 10.0. Mais au moins maintenant, il fonctionne pour les deux environnements ...

Answer 2

Cet article semble avoir quelques idées pré-MVC à l'esprit:

• fichiers de ressources ne sont pas entièrement pris en charge dans le MVC (au moins pas sans hacks) - voir Resource Files and ASP.NET MVC Projects. Toutefois, vous pouvez utiliser embedded resources ou utiliser un ResourceManager pour charger des ressources externes.
• La définition de la langue utilisateur en fonction des paramètres du navigateur est généralement le mauvais choix. Au lieu de cela, vous devez utiliser l'URL pour transmettre les informations de culture afin que les moteurs de recherche puissent les explorer et les indexer. La localisation est contenu pas personnalisation. S'appuyer sur les en-têtes pour afficher la bonne langue peut être frustrant pour les utilisateurs assis derrière des pare-feu qui changent ces en-têtes. L'utilisation de l'URL pour choisir la langue donne un contrôle direct sur la langue à l'utilisateur.

Voir ma réponse à ASP.NET MVC 5 culture in route and url pour une façon MVC pure de faire la localisation.

Fondamentalement, la réponse à votre question est dans le this link - par défaut les ressources dans App_GlobalResources sont internes et ne peuvent pas être utilisées sans modification des paramètres. Ils nécessitent une attention particulière lors du déploiement ou ils ne seront pas déployés avec votre application. App_LocalResources ne sont pas pris en charge dans MVC (ils sont pour les pages ASP.NET héritées). En bref: évitez App_GlobalResources et App_LocalResources (qui a son propre ensemble de problèmes) dans MVC.

Hors-sujet: Il semble que vous utilisez également un contrôleur de base (en raison de la méthode Initialize). Ceci couple étroitement votre application ensemble. Une meilleure façon est d'utiliser des filtres globaux, qui peuvent chacun contenir une seule fonctionnalité. Voir this answer.