Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

We're using resource files to handle UI-constants. This is working out alright. The problem is that we're getting lots of 'High'-level logging entries in ULS. They look like the following:

Failed to open the file 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Resources\ProjectResources.en-US.resx'.
#20015: Cannot open "": no such file or folder.
(#2: Cannot open "": no such file or folder.)
Failed to read resource file "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Resources\ProjectResources.en-US.resx" from feature id "(null)".

We are only going to use english language resources for now, but what's nice with resource files is that we can add support for other languages later.

Our resource file has the name ProjectResources.resx. If I add a file named ProjectResources.en-US.resx, I can't deploy my solution until I add my constants there as well (what happened to the fallback mechanism?). After I've added my constants to the en-US file, I obviously want to delete my constants in the root file to prevent having duplicate entries. The problem is then that any other language locale won't find any resource file.

So my question is: How can I structure my resource files to

  1. Not have my ULS-log spammed, even if it works, and
  2. Avoid duplicate entries in the resource files?
share|improve this question
    
Still no propre way to resolve this problem ? I have the same issue with my SharePoint 2013 –  Abdessamad Nov 11 at 12:22
    
I haven't found a way unfortunately –  tarjeieo Nov 12 at 9:24

2 Answers 2

I have the same issue in our SharePoint projects, but gave up on it because it appeared that SharePoint wasn't applying the resource fallback mechanism like I expected it to. Then I saw this post and decided to research this a little.

I came across this article http://msdn.microsoft.com/en-us/library/ee696750.aspx and it says that a Default resource is:

Also known as a fallback resource, default resource files contain strings localized for the default culture, such as English. They are used if no localized resource files for the specified language can be found. Default resources do not have separate files, they are stored in the main application assembly.

I didn't know this, especially that the default resources are embedded into the assembly. The instructions to add this are unclear:

To specify default resource files in Visual Studio SharePoint projects, select Invariant Language (Invariant Country) in the culture list of the Add Resource dialog box when you add a resource file.

Turns out this is in the Properties of the Visual Studio project. Click on the Resources tab, and you'll see a message that the project doesn't contain any default resource files.

However, I don't see the ability to choose the culture of the default resource file.

By the way, I've seen that this issue only happens to Resource files in 14\Resources, not to the ones deployed to App_GlobalResources in IIS.

I'll keep looking and update my answer if I figure it out.

share|improve this answer

SharePoint fallback is not like the ASP.NET fallback to the invariant culture; is first use the thread CurrentUICulture, then fallback to the SPWeb.Language: http://blogs.msdn.com/b/sharepointdev/archive/2011/07/01/localizing-the-sharepoint-user-interface-by-using-resource-files-sanjay-arora.aspx

share|improve this answer
1  
So are you saying that this is not fixable? –  tarjeieo Oct 25 '11 at 11:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.