I have a simple Sandbox Solution with a Content Type in it. The Content Type simply inherits from the Item content type. It adds no additional fields to it.

I've added a Feature Resource file to my project and entered one key/value pair for my content type name:

  <data name="Ctype1Name" xml:space="preserve">
    <value>My Content Type</value>

I then reference it from my content type definition in the elements file:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <!-- Parent ContentType: Item (0x01) -->
  <ContentType ID="0x01006d8d9c500d1f4f0b9cb80f36f177d7ff"
               Group="Custom Content Types"
               Description="My Content Type"

When I attempt to activate the feature, either through Visual Studio's Deploy command, or via manual solution deployment (i.e. upload .wsp, activate solution, activate feature), I get an error:

Microsoft.SharePoint.SPInvalidContentTypeNameException: The content type name '$Resources:Ctype1Name;' cannot contain: \ / : * ? " # % < > { } | ~ & , two consecutive periods (..), or special characters such as a tab. at Microsoft.SharePoint.Administration.SPElementDefinitionCollection.ProvisionFieldsAndContentTypes(SPFeaturePropertyCollection props, SPSite site, SPWeb web, Boolean fForce) at Microsoft.SharePoint.Administration.SPElementDefinitionCollection.ProvisionElements(SPFeaturePropertyCollection props, SPWebApplication webapp, SPSite site, SPWeb web, Boolean fForce) at Microsoft.SharePoint.SPFeature.Activate(SPSite siteParent, SPWeb webParent, SPFeaturePropertyCollection props, Boolean fForce) at Microsoft.SharePoint.SPFeatureCollection.AddInternal(SPFeatureDefinitio...

I've tried recycling the User Code Service, rebooting the machine, etc, and I still get the error. When I change the Solution from a Sandboxed to a Farm Solution, I no longer get the error.

It appears that the feature activation logic is failing to localize the Content Type name, and as a result it is being passed through with the RESX reference (i.e. "$Resources:Ctype1Name;") all the way through, which violates the content type naming.

Oddly, when I use localized strings in my Feature Name/Description, or in a Site Column's Display Name, things work just fine. I am only having the problem with Content Types at the moment (not to say other elements won't work quite right, I just haven't tested them). For example the following provisions just fine:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">  
       Group="Custom Site Columns">

Can anyone confirm this is an issue and maybe point me to any resources indicating such?


Update: Given that I experienced this issue with a manual .wsp deployment, I wasn't expecting different results, but I also tried with Visual Studio 11 Beta and I get the same experience.

I am running SharePoint Server 2010 Enterprise. I think I'm running RTM. In Central Admin, my version numbers are listed as: 14.0.4763.1000 (it's a dev server/farm). I have since upgraded to SP1 + December 2012 CU and still having the issue.

  • Did you specify your resource file as the default resource file in your feature.xml? DefaultResource="filename"
    – sssreddy
    Mar 6, 2012 at 22:45
  • Doesn't apply here. As I mentioned, I am using a Feature Resource file, and the default behavior for a feature is to look to the \FeatureName\Resources\Resource.resx when a DefaultResourceFile attribute is not specified. msdn.microsoft.com/en-us/library/ms436075.aspx
    – Brian
    Mar 7, 2012 at 2:23

3 Answers 3


This is indeed by design. Seeing as sandbox solutions are not allowed to deploy to the file system and content type / field (or any non- aspx / ascx resource, i.e. anything created declaratively through XML) can only be localized using Resource files stored in the RESOURCES folder in the 14 hive, this will not work. Features titles and descriptions CAN be localized by the way, by adding a feature resource

P.S. what you describe should not work for fields, very strange. Also, the lookup order you describe should work for resources used in the feature XML only, not in any of the elements included in the feature :-S.


Using the following code, deploying a localized content type is still easy

First, add a feature receiver and add the following to featureactivated method:

var web = properties.Feature.Parent as SPWeb;
var types = from property 
  in properties.Feature.Properties.OfType<SPFeatureProperty>()
  where property.Name.StartsWith("CType_", StringComparison.OrdinalIgnoreCase) 
  select property;

foreach (SPFeatureProperty featureProperty in types)
  var typeInfo = featureProperty.Value.Split(',');
  var contentType = web.ContentTypes[new SPContentTypeId(typeInfo[0])];
  contentType.Name = Resources.ResourceManager.GetString(typeInfo[1]);
  contentType.Description = Resources.ResourceManager.GetString(typeInfo[2]);
  contentType.Group = Resources.ResourceManager.GetString(typeInfo[3]);

Then, add a propety to the feature template xml

  <Property Key="GloballyAvailable" Value="true" /> <!-- added visual studio -->
  <Property Key="CType_MyAnnouncement" Value="0x010400ede484e30e4b4b84b447c794485359f3,ctype_MyAnnouncement,ctype_MyAnnouncement_desc,ctypegroup_MyTypes"/>

This property has a comma separated type info value:


The resource keys are keys for resources in satellite assemblies, so follow the guidelines in http://msdn.microsoft.com/en-us/library/gg615453.aspx on how to include those in your package

  • I understand that Sandbox Solutions are not allowed to provision to the file system. Can you point to "proof" (i.e. MSDN documentation) that explicitly indicates "content types/fieds ... can ONLY be localized using Resource files stored in the RESOURCES folder in the 14 hive" ?? Can I also ask - what is the point of localizing the Feature name/description, and not any of the elements within it? OK, so I can see a "Spanish" version of my feature name, but all my content types are in English...The elements within the features are what users interact with on a day to day basis...
    – Brian
    Mar 15, 2012 at 19:55
  • Also the "should not work for fields, very strange." is what bothers me about this. It's not just the Field elements, there are others it works for as well. Almost like they started to make it work with Feature Resx files, but then had to rush delivery of it or something...
    – Brian
    Mar 15, 2012 at 19:56
  • Going to research this myself now too, very, vey strange. Can't find a single line stating a content type name resource HAS to be in the RESOURCES folder in the 14 hive either. Will get back on this
    – Colin
    Mar 15, 2012 at 20:13
  • 1
    Well, checked it out, everything but ListInstance title / desc / url and Contenttype name / desc / group can be localized using feature resources. Weird...
    – Colin
    Mar 16, 2012 at 1:35
  • Cannot be localized of course, see the update
    – Colin
    Mar 16, 2012 at 3:08


Just heard back from Microsoft. They also offer the following as a solution. They indicate that by changing the Inherits attribute to "FALSE" (or omitting it), and by prefixing the RESX key with the "_Res," value, this is a way of achieving this.

<ContentType ID="0x01006d8d9c500d1f4f0b9cb80f36f177d7ff"
Group="Custom Content Types"
Description="My Content Type"
 <!-- todo: redefine all fields from base type since Inherits now equals FALSE -->

I tested the above and it works on my machine. I think there are too many questions to "recommend" this as a solution until I get more details about this from Microsoft. It just feels like a hack and something that could get deprecated without notice in the future. Leaving my original answer below for historical reference.

Original Answer:

I just spoke with Microsoft Support (I ended up opening a ticket). After they troubleshoot, they tell me nothing more than I already know: the pieces that provision Fields and Content Types (and likely other elements) behave differently. They indicate this is "by design" (or at least how the current implementation of the product is coded to work). They offer two workarounds:

  1. Create a Farm Solution to house a shared RESX file. Put my resources (strings) in there and reference them using the filename in the resource key reference in my elements files (i.e. $Resources:My14HiveResxFile,MyResxKey). This won't work for anyone in an environment where Farm Solutions are simply not allowed, as is the case on my current on premise deployment, but another example where I think this would apply would be SharePoint Online.

  2. Maintain separate language/locale specific versions of your elements. It should be obvious as to why this is not a good idea.

I am pushing for clearer documentation on this topic as the two links previously referenced (Restrictions on Sandbox Solutions in SharePoint 2010 and Localization of Sandboxed Solutions in SharePoint 2010) seem to, somewhat, contradict each other. The first indicates:

Resource (.resx) files cannot be deployed in a sandboxed solution, but there are ways to localize sandboxed solutions without deploying resource files to the server file system. For more information, see Localization of Sandboxed Solutions in SharePoint 2010.

The second link above points to another "How To" on localizing the Feature Name and Description. One could easily deduce that because I can localize the Feature Name/Description with a .RESX file, I could also localize attributes within Elements files, such as and . As I mentioned in the question, it does work with , but not with elements (and a few others I have since looking into).

I sure hope this story improves in SharePoint vNext. In fact, it better, or else they may want to look at the Content Type Designer in Visual Studio 11 - this designer interface supports "looking up" content type names from a Sandboxed Feature .RESX file, something that isn't supported by the platform itself.

  • Logged as bug with Visual Studio 11 site, though I believe it should be logged with SP vNext team: connect.microsoft.com/VisualStudio/feedback/details/731660/…
    – Brian
    Mar 16, 2012 at 19:28
  • Also, MS Support has indicated they will TRY to get a documentation update published and/or contact the relevant product teams to hopefully get this resolved.
    – Brian
    Mar 16, 2012 at 19:28

I just tried it and got the same error.

Looks like sandbox solutions do not have access to resource file although feature attributes can be localized using feature resources.


  • Thanks for the info. I'll add another link that is relevant here: msdn.microsoft.com/en-us/library/gg615460.aspx. While this is a step in the right direction, it doesn't fully answer the (now updated) question and provide concrete evidence to support it. I've updated the question to indicate that I am able to localize, for example, a Site Column's display name. One would think that localizing a Site Column would mean I could localize a ContentType. While I won't yet mark as answer, I will upvote.
    – Brian
    Mar 7, 2012 at 14:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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