Sandbox Content Type and Resource (RESX) File

Question

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>
  </data>

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"
               Name="$Resources:Ctype1Name;"
               Group="Custom Content Types"
               Description="My Content Type"
               Inherits="TRUE"
               Version="0">
    <FieldRefs>
    </FieldRefs>
  </ContentType>
</Elements>

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/">  
  <Field
       ID="{ce45f1c9-e76d-41fb-abb6-253aa7538ae8}"
       Name="MySitecol"
       DisplayName="$Resources:MySiteColumnName"
       Type="Text"
       Required="FALSE"
       Group="Custom Site Columns">
  </Field>
</Elements>

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

Thanks!

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.

Answer 1

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.

Update:

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]);
  contentType.Update(true);
}

Then, add a propety to the feature template xml

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

This property has a comma separated type info value:

CONTENTTYPEID,RESOURCEKEYFORNAME,RESOURCEKEYFORDESC,RESOURCEKEYFORGROUP

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

Answer 2

UPDATE!!

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"
Name="$Resources:_Res,Ctype1Name;"
Group="Custom Content Types"
Description="My Content Type"
Inherits="FALSE"
Version="0">
<FieldRefs>
 <!-- todo: redefine all fields from base type since Inherits now equals FALSE -->
</FieldRefs>
</ContentType>

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.

Answer 3

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.

http://msdn.microsoft.com/en-us/library/gg615454.aspx