We are seeking to gradually move custom artifacts to new solutions (wsp's) and I'm stuggling with loading resource strings from xml/code in original package (XXX.Package.wsp).
Resource files are now situated in new package XXX.Package.Resources.wsp.

Both assemblies are full trust/GAC deploys.
Both assemblies are signed with same strong name key file.

E.g. in feature.xml, the following reference:


will result in exception:

System.Resources.MissingManifestResourceException: Could not find any resources appropriate for the specified culture or the neutral culture.  Make sure "XXX.Package.Resources.NameOfConfigFile.resources" was correctly embedded or linked into assembly "XXX.Package.Resources"
 at compile time, or that all the satellite assemblies required are loadable and fully signed.   
 at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)
 at ...
 at ...

Can someone please shed light on how to achieve this?

Do I need to write my own ExpressionBuilder and use this instead of the default ResourceExpressionBuilder, or is there a more standard way?


Localization of feature.xml differs from localizing something else. As by Microsoft's reference, you have to create a special Feature resource file (which will be stored along with the feature) in order to do that:

Based on my experience, if you deploy your resources into "Resources" mapped folder (in 14 hive), they will also be available from feature.xml file.

Also if you deploy resources to the "Resources" mapped folder, you will be able to fetch them programmatically by using SPUtility.GetLocalizedString function. In this case, it obviously doesn't matter by which wsp the resources were deployed: once you have the resx file in "Resources" folder, it will be available via SPUtility.GetLocalizedString.

On the other hand, resources deployed into "Resources" SharePoint mapped folder are not easily accessible from aspx and ascx markup (i.e. they won't be deployed to App_GlobalResources). Though you can use App_LocalResources after some tricking.

If you're embedding resources into assembly, it's even a bit more tricky, though has it's own benefits.

As you can see, the topic is really vast, and particular solution tightly depends on your way of implementing localization. If you're interested in some other particulars, please don't hesitate creating separate questions. As of now, I can recommend some very good links for you to read:

  1. Localizing SharePoint Solutions (MSDN)
  2. Localization of Sandbox Solutions in SharePoint 2010 (MSDN) (actually any solution can be localized that way, this is embedded resources approach)
  3. Use App_LocalResources in SharePoint 2010 Visual Web Parts (post by my collegue, SharePoint MVP Alexey Sadomov)
  4. Provisioning resources to App_GlobalResources in SharePoint 2010 (post by SharePoint MVP Waldek Mastykarz)

By the way, you might also be interested reading about approach of packaging multiple projects into one WSP, so that you don't have a whole bunch of WSP's yet in the same time in Visual Studio they are separate projects: https://sharepoint.stackexchange.com/a/12105/1430.

  • Thanks, Andrey, you pointed me in the right direction. Problem with existing code was that resources were referenced statically in code-behind XXX.Package.Resources.Key and not with SPUtility.GetLocalizedString("$Resources:Key", "ResourceFileName", language);. Correcting this to SPUtility.GetLocalizedString( ... ) solved the error. – user1023810 Feb 20 '13 at 13:36
  • Great, you're welcome! :) btw, correct way to say "thanks" here on StackExchange is to upvote the answer and mark it as accepted ;) – Andrey Markeev Feb 20 '13 at 13:41
  • Thanks. Haven't got enough reputation to upvote but rightfully marked you anwser as accepted. – user1023810 Feb 20 '13 at 13:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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