Globalization incorrectly uses default culture in all scenarios after deployment

Question

Local Environment:
Win10 x64
VS 2015 Pro Update 3
IIS 10.0 Express

Production Environment:
Win server 2012 R2
IIS 8.5

Im developing an ASP.NET 4.6.1 MVC app that needs to be supported in english, danish, and dutch. I implement the neutral cultures as im only interested in the language and not in specifics. I use satellite assemblies (as some would call them) or rather Resource.resx files for my translations. First approach i followed this often referenced post and it works perfectly locally. As soon as i deploy it to the production environment translations stop working. I set the threads according to database values: And i have verified that this method is always correctly executed in the production environment. I have tried setting the threads like in the referenced post as well which also works fine locally, but not in production. And i have even tried setting it directly as the top of my views using razor to no avail.
What strikes me as really odd is that i had it working once in the production environment after i did some fiddling, but im pretty sure i didnt really do anything and suddenly it worked. Sadly it stopped working after i deployed an update to the app, and i havent been able to get it to work since. I have since tried messing with all settings in the .NET environment on the IIS for this website and for the root directory:
But even specifying da-DK or da as the culture here or directly in the web.config of my app or hardcoding the thread to use da as the culture doesnt help at all. Funny thing is that number and date formatting correctly changes. So it doesnt seem to be an issue with the thread not having its culture changed, but rather IIS refusing to use the other resource files. When deployed the folder structure has the da folder in bin and it contains a file named Resources.resources.resx which i believe is correct. I tried having the resource files located in a class library as the article suggests, but also in a folder in the same project out of frustration. The resource files are set to public accessibility and are compiled as Embedded Resources without copying files.

So my question is, how come IIS refuses to use any other resource file than the default? And how is it possible that it worked once ? At this point im considering just taking translations to the database, because at least that works. What suggestions do you have? I believe the .NET environment on the IIS has all the necessary languages installed as they are visible in the .NET globalization settings, but i might be wrong?

Update: I tried as suggested by NightOwl, again it works locally(VS debugging) and even if i host the deployed files in iisexpress on my machine. But it still fails on the production environment. The method suggested is similar to this but still without success. Im starting to think the solution is to upgrade to iis 10 in the production environment.

Answer 1

That article seems to have some pre-MVC ideas in mind:

• Resource files are not supported fully in MVC (at least not without hacks) - see Resource Files and ASP.NET MVC Projects. However, you can use embedded resources or use a ResourceManager to load external resources.
• Setting user language according to browser settings is usually the wrong choice. Instead, you should use the URL to pass the culture information so search engines can crawl and index them. Localization is content not personalization. Relying on headers to display the right language can be frustrating to users that are sitting behind firewalls that change those headers. Using the URL to choose language gives direct control over the language to the user.

See my answer to ASP.NET MVC 5 culture in route and url for a pure MVC way to do localization.

Basically, the answer to your question is in the this link - by default resources in App_GlobalResources are internal and cannot be used without modification to the settings. They require special attention during deployment or they will not be deployed with your application. App_LocalResources are not supported in MVC at all (they are for legacy ASP.NET pages). In short: avoid App_GlobalResources and App_LocalResources (which has its own set of problems) in MVC.

Off-topic: It looks like you are also using a base controller (because of the Initialize method). This tightly couples your application together. A better way is to use global filters, which can each contain a single piece of functionality. See this answer.

Answer 2

The issue was caused by the Nuget package SimpleImpersonation, which appears to change the culture of the current thread behind the scenes. It seems like it changes it back to default after it is disposed, but as i was setting the culture while while the reference was valid, it always defaulted back to en-US. It is still weird that it worked locally in IIS Express 10.0. But at least now it works for both environments...