Problem with resolving resource strings in Sharepoint via SPUtility.GetLocalizedString

Method SPUtility.GetLocalizedString can be used in order to get translated string from your resource file in runtime in Sharepoint web site. Resource files should be located in 14/Resources folder. We often use it during development. Recently we faced with strange situation: there was a farm with 2 WFEs. On this farm we updated wsp package which with other artifacts contained updates for provisioning resources, i.e. we added several new strings into resx files which are provisioned to 14/Resources. After wsp upgrade we ran iisreset on both WFE (SPUtility.GetLocalizedString caches results).

After that problem occurred: SPUtility.GetLocalizedString showed translated string from resx file only on one WFE, while on another it didn’t find it. We checked that resx files were updated correctly on problematic WFE, and that they are the same as on WFE where everything was working.

During investigating the problem in ULS I found the following errors:

Failed to look up string with key "key_name", keyfile MyResources
Localized resource for token 'key_name' could not be found for file with path: "(unavailable)"

And it was strange because as I said resx files were updated correctly. Also during investigation we tried to copy resx files into App_GlobalResources, but it didn’t help.

In the project we had the following provisioning resources:

• MyResources.resx – default English culture
• MyResources.fi-fi.resx – Finnish resources
• MyResources.nl-nl.resx – Dutch resources

I created simple application layouts page which calls SPUtility.GetLocalizedString with 3 locale ids (English = 1033, Finnish = 1035 and Dutch = 1043) and opened it in context of site on problematic WFE. It successfully found Finnish and Dutch resources, but not default English resources. How it could be if MyResources.resx was the same as in working WFE?

I went to 14/Resources folder in order to check MyResources.resx more carefully, and found that there was another culture-specific resource file for English locale: MyResources.en-us.resx. It was added manually by someone for some testing and was not deleted after that. Of course it didn’t contain our new strings. But SPUtility.GetLocalizedString found this file and as it was culture-specific, it had more priority over default culture file MyResources.resx. When we deleted MyResources.en-us.resx from problematic WFE, it become working. Hope that this story will help you if you will face with the same problem.