Corey Roth [MVP] : CAML, Feature

How to: Deploy Metadata Navigation without using code

CoreyRoth — Wed, 09 Feb 2011 22:37:29 GMT

As someone who focuses mostly on ECM and Search, I am a huge fan of the new Metadata Navigation feature on document libraries in SharePoint 2010. It provides a great alternative to folders when it comes to navigating your document libraries. A list administrator can configure Metadata navigation on the document library settings page. However, I prefer to make changes using CAML or code so that I can deploy them easily to other environments. Usually, my first choice is with CAML, so I did some digging today and I discovered the trick to deploying your Metadata navigation settings using a SharePoint feature.

When I first started investigating this, I assumed it might be some new element or attribute inside the schema.xml file of the list. It turns out my assumption was incorrect. We actually set this by assigning some XML to the client_MOSS_MetadataNavigationSettings property on the root folder of the list. We can assign this value using code, but you know I prefer to use CAML. We can use the PropertyBag element to make this happen. Before we look at the PropertyBag element itself though, let’s look at the underlying XML. Let’s take my list here with three items selected for Metadata Navigation: a site column named DocumentType, the Content Type of the documents in the library, and the Folders in the library itself. Here is what the XML will look like.

<MetadataNavigationSettings SchemaVersion="1" IsEnabled="True" AutoIndex="True">
  <NavigationHierarchies>
    <FolderHierarchy HideFoldersNode="False" />
    <MetadataField FieldID="3c6f8f63-0616-437c-80eb-cf7cba0d88cc" FieldType="Choice" CachedName="DocumentType" CachedDisplayName="DocumentType" />
    <MetadataField FieldID="03e45e84-1992-4d42-9116-26f756012634" FieldType="ContentTypeId" CachedName="ContentTypeId" CachedDisplayName="Content Type" />
  </NavigationHierarchies>
  <ManagedIndices>
    <ManagedIndex IndexID="3c6f8f63-0616-437c-80eb-cf7cba0d88cc" IndexFieldName="DocumentType" IndexFieldID="3c6f8f63-0616-437c-80eb-cf7cba0d88cc" />
  </ManagedIndices>
</MetadataNavigationSettings>

The first line seems to always be the same. It enables the Metadata Navigation and it will take care of automatically adding new index columns when AutoIndex is set to true. The NavigationHierarchies section actually defines which fields will be used for Metadata navigation. If you want to navigate by folders, add a FolderHierarchy element and set HideFoldersNode to false. If you set it to true, folder navigation will not be present. The MetadataField element defines which fields to use for navigation. You need the GUID for each site column to include. You can get this from your list’s schema.xml file. You then need to specify the FieldType. Remember that it only supports Single-value Choice (Choice), Managed Metadata (TaxonomyFieldType) , and Content Type (ContentTypeId) field types. You then need to specify the field name in the CachedName field and then you can customize the display name as you see fit with CachedDisplayName. The last thing to note here is that you have to create a Managed Index for any choice fields you add. This is why you see a ManagedIndex element with the DocumentType field. Set the IndexId and IndexFieldId attributes equal to the Id of the field.

At this point, we are ready to assign this XML to the the client_MOSS_MetadataNavigationSettings property. We need to encode the above XML, because it is being stored inside an attribute of another XML document. Here is what your elements.xml file would look like.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <PropertyBag Url="Shared Documents" ParentType="Folder" RootWebOnly="FALSE" xmlns="http://schemas.microsoft.com/sharepoint/">
    <Property Name="client_MOSS_MetadataNavigationSettings" Value="&lt;MetadataNavigationSettings SchemaVersion=&quot;1&quot; IsEnabled=&quot;True&quot; AutoIndex=&quot;True&quot;&gt;&lt;NavigationHierarchies&gt;&lt;FolderHierarchy HideFoldersNode=&quot;True&quot; /&gt;&lt;MetadataField FieldID=&quot;3c6f8f63-0616-437c-80eb-cf7cba0d88cc&quot; FieldType=&quot;Choice&quot; CachedName=&quot;DocumentType&quot; CachedDisplayName=&quot;DocumentType&quot; /&gt; &lt;MetadataField FieldID=&quot;03e45e84-1992-4d42-9116-26f756012634&quot; FieldType=&quot;ContentTypeId&quot; CachedName=&quot;ContentTypeId&quot; CachedDisplayName=&quot;Content Type&quot; /&gt; &lt;/NavigationHierarchies&gt;&lt;ManagedIndices&gt;&lt;ManagedIndex IndexID=&quot;3c6f8f63-0616-437c-80eb-cf7cba0d88cc&quot; IndexFieldName=&quot;DocumentType&quot; IndexFieldID=&quot;3c6f8f63-0616-437c-80eb-cf7cba0d88cc&quot; /&gt;&lt;ManagedIndex IndexID=&quot;d31655d1-1d5b-4511-95a1-7a09e9b75bf2&quot; IndexFieldName=&quot;Editor&quot; IndexFieldID=&quot;d31655d1-1d5b-4511-95a1-7a09e9b75bf2&quot; /&gt;&lt;/ManagedIndices&gt;&lt;/MetadataNavigationSettings&gt;" Type="string" />
  </PropertyBag>
</Elements>

It’s kind of hard to read the contents of the Property element, but it is just the encoded version of the XML above. As for the PropertyBag element, you just specify the relative Url to the document library on your site. In this case, it’s Shared Documents. Always set ParentType to Folder and RootWebOnly to false. At this point, you can activate this feature after you have deployed your document library and it will enable the Metadata navigation. Here is what the Metadata Navigation settings page looks like.

Here is what my document library looks like with the navigation enabled.

It’s pretty easy to set this up as you can see. Keep in mind that if you set this value, it will overwrite any values previously stored. This includes any Key Filters or Indexes that might already be present on the list.

Speaking of Key Filters, we can add them to the document library using the client_MOSS_MetadataNavigationSettings as well. Let’s look at some more XML. In this case, I am adding key filters for DocumentType, All Tags, and Modified By (editor).

<MetadataNavigationSettings SchemaVersion="1" IsEnabled="True" AutoIndex="True">
  <KeyFilters>
    <MetadataField FieldID="3c6f8f63-0616-437c-80eb-cf7cba0d88cc" FieldType="Choice" CachedName="DocumentType" CachedDisplayName="DocumentType" />
    <MetadataField FieldID="23f27201-bee3-471e-b2e7-b64fd8b7ca38" FieldType="TaxonomyFieldTypeMulti" CachedName="TaxKeyword" CachedDisplayName="All Tags" />
    <MetadataField FieldID="d31655d1-1d5b-4511-95a1-7a09e9b75bf2" FieldType="User" CachedName="Editor" CachedDisplayName="Modified By" />
  </KeyFilters>
  <ManagedIndices>
    <ManagedIndex IndexID="d31655d1-1d5b-4511-95a1-7a09e9b75bf2" IndexFieldName="Editor" IndexFieldID="d31655d1-1d5b-4511-95a1-7a09e9b75bf2" />
  </ManagedIndices>
</MetadataNavigationSettings>

The elements are pretty similar to that of the NavigationHierarchies element. You add one MetadataField element for each field you want with the same attributes as before. However, a few more fields types are supported such as Person or Group (User). It also recognizes Enterprise Keywords through the use of the All Tags (TaxonomyFieldMulti) filter. You can also do Date and Time fields as well as Number fields too. I also added the ManagedIndex field for Editor (the Modified By filter). You can probably leave the indexes out since AutoIndex is true, but if you run into issues, you can add them manually as you see above. You can deploy KeyFilters and NavigationHierarchies elements at the same time. You’ll need to encode the XML again just as you did before. When you activate the feature, you’ll have Key Filters enabled on your document library.

Using the PropertyBag element, you can easily add metadata navigation to your document libraries. This is a great alternative to defining these settings using code.

Deploying an External List via Feature using CAML #sp2010

CoreyRoth — Thu, 25 Feb 2010 19:33:13 GMT

I’ve been talking a lot about external lists lately as you may know. They are so easy to create with SharePoint Designer, but you wouldn’t really deploy them to production that way would you? Of course not! We need a feature. At first, you might think generating all of that CAML might be too difficult, but remember we can use the Save Site as Template page to generate a .wsp file for us. Using this we can import it into Visual Studio and learn what CAML we need to use.

We’re going to start with the same external list from yesterday. You can build your own using SharePoint Designer as described in my BCS post.

Once you are happy with your list, go to Site Settings –> Save Site as Template. Fill in the fields and it will save a solution package in your solution gallery of your site collection. Save the .wsp file to disk and we’re ready to begin. Once you have your solution package, open Visual Studio 2010, create a new project, and use the Import SharePoint Solution Package project template. You will be prompted for what site to use and where the package file is. On the next step, you will be prompted for what you want to import.

The solution package has every site column, content type, page, list, etc, on the site so there is a lot to sift through. However, the only thing we really need is the list instance in question (in my case Products). You will want to unselect everything else as it will take forever to import if you don’t.

Quick Tip: There isn’t a select all button, so press Ctrl+A, and then unclick a checkbox to deselect everything.

On the next step you will get a warning about dependencies. Go ahead and just say yes and your project will import. Your project will likely have a bunch of stuff you don’t really care about. All that you really need is what it is created in List Instances. Your list instance might look something like this.

At this point, I created a new project because I want to keep things clean. Create a new project and create a new List Definition. At this point, you will have a schema file and two new elements files. The elements.xml file with the list template can be deleted since I don’t want users creating new versions of this list. Before we start digging into the CAML that is required to make an external list work, let’s go back and look at SharePoint Designer so we can remember what our application definition looked like.

The reason I show you this is because these values we’re going to see when we take a look at our elements.xml file. Here is the file that came from the site export.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ListInstance FeatureId="{00bfea71-9549-43f8-b978-e47e54a10600}" TemplateType="600" Title="Products" 
                Description="" Url="Lists/Products" CustomSchema="Files\Lists\Products\Schema.xml" 
                HyperlinkBaseUrl="http://sp2010/Test" RootWebOnly="FALSE" 
                xmlns="http://schemas.microsoft.com/sharepoint/">
    <DataSource>
      <Property Name="Entity" Value="Products" />
      <Property Name="EntityNamespace" Value="http://sp2010/test" />
      <Property Name="LobSystemInstance" Value="bcs_test" />
      <Property Name="SpecificFinder" Value="Read Item" />
    </DataSource>
  </ListInstance>
</Elements>

A couple of things to note here. First, the TemplateType is 600. We can only presume this is the list template id for an external list. The other thing of note is the new DataSource element. This was not in previous versions of SharePoint. As you might notice here, these values correspond to what we see on the external content type. This is what you will change should you decide to rename the entity in or change the LobSystemInstance name. This XML is highly useable in our own feature, but I am going to remove some of the unnecessary attributes such as FeatureId and CustomSchema. I’m also going to give it a new Title so that we know this is a different list. Here is what my new elements.xml looks like.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ListInstance TemplateType="600" Title="Products - Deployed by Feature" Description="" 
                Url="Lists/ProductsDeployedByFeature" HyperlinkBaseUrl="http://sp2010/Test" 
                RootWebOnly="FALSE" xmlns="http://schemas.microsoft.com/sharepoint/">
    <DataSource>
      <Property Name="Entity" Value="Products" />
      <Property Name="EntityNamespace" Value="http://sp2010/test" />
      <Property Name="LobSystemInstance" Value="bcs_test" />
      <Property Name="SpecificFinder" Value="Read Item" />
    </DataSource>
  </ListInstance>
</Elements>

Honestly, I think I can get rid of HyperLinkBaseUrl as well. It doesn’t seem to matter though, I deployed it to a few other sites and it seems to work fine. Now let’s take a look schema.xml. It’s actually pretty small which is nice compared to the files we were used to in the past.

<?xml version="1.0" encoding="utf-8"?>
<List Title="Products" Direction="none" Url="Lists/Products" BaseType="0" Type="600" 
      FolderCreation="FALSE" DisableAttachments="TRUE" Catalog="FALSE" RootWebOnly="FALSE" 
      SendToLocation="|" ImageUrl="/_layouts/images/itgen.gif" xmlns:ows="Microsoft SharePoint" 
      xmlns:spctf="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms" 
      xmlns="http://schemas.microsoft.com/sharepoint/">
  <MetaData>
    <ContentTypes>
      <ContentType ID="0x01" Name="Item" Group="List Content Types" Description="Create a new list item." FeatureId="{695b6570-a48b-4a8e-8ea5-26ea7fc1d162}">
        <Folder TargetName="Item" />
        <FieldRefs>
          <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType" />
          <FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" Required="TRUE" ShowInNewForm="TRUE" ShowInEditForm="TRUE" />
        </FieldRefs>
        <XmlDocuments>
          <XmlDocument NamespaceURI="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
            <FormTemplates xmlns="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
              <Display>ListForm</Display>
              <Edit>ListForm</Edit>
              <New>ListForm</New>
            </FormTemplates>
          </XmlDocument>
        </XmlDocuments>
      </ContentType>
    </ContentTypes>
    <Fields>
      <Field DisplayName="BDC Identity" Hidden="FALSE" Name="BdcIdentity" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="BdcIdentity" Type="Text" />
      <Field DisplayName="Name" Hidden="FALSE" Name="Name" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Name" Type="Text" />
      <Field DisplayName="Id" Hidden="FALSE" Name="Id" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Id" Type="Integer" />
      <Field DisplayName="Color" Hidden="FALSE" Name="Color" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Color" Type="Text" />
      <Field DisplayName="Description" Hidden="FALSE" Name="Description" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Description" Type="Text" />
      <Field DisplayName="Price" Hidden="FALSE" Name="Price" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Price" Type="Decimal" />
    </Fields>
    <Forms />
    <Views>
      <View DisplayName="Products Read List" DefaultView="TRUE" BaseViewID="1" Type="HTML" MobileView="TRUE" MobileDefaultView="TRUE" ImageUrl="/_layouts/images/generic.png" XslLink="main.xsl" WebPartZoneID="Main" WebPartOrder="1" Url="Read List.aspx" SetupPath="pages\viewpage.aspx">
        <XslLink>main.xsl</XslLink>
        <Method Name="Read List" />
        <Query>
          <OrderBy>
            <FieldRef Name="Name" />
          </OrderBy>
        </Query>
        <ViewFields>
          <FieldRef Name="Name" ListItemMenu="TRUE" LinkToItem="TRUE" />
          <FieldRef Name="Id" />
          <FieldRef Name="Color" />
          <FieldRef Name="Description" />
          <FieldRef Name="Price" />
        </ViewFields>
        <RowLimit Paged="TRUE">30</RowLimit>
        <Aggregations Value="Off" />
      </View>
    </Views>
  </MetaData>
</List>

As you can see it’s pretty clean. It again uses the Type of 600. In the ContentTypes section, it does define a regular list item, but it doesn’t actually add any of the fields from the external list there. The Fields element has a field defined for each field in my external content type. As you can see there is nothing special about the way they are defined. The only one of note is the BdcIdentity field which I assume is required to keep track of the ID that ties back to the BCS itself. The View is surprisingly clean as well. The XslLink and Method elements are new. I assume we can use XslLink to customize how the view is rendered, but I didn’t actually see a main.xsl file generated in the solution package anywhere. The Method element I can only assume corresponds to the name of the finder method Read List which we have seen above. The rest is pretty simple. It just has a FieldRef for each column in my external content type.

I can pretty much use the Schema.xml file as is. I did change the Title and Url attributes at the top but that is it. At this point my new feature to deploy this is ready to go. Here is what it looks like in Visual Studio.

Deploy your solution and have it activate your feature. The new list won’t show up automatically in the navigation on the side, but it will be there. Just go to the URL directly or view the lists on your site to get there. Here it is on my new site.

As you can see it’s really not that hard to deploy an external list to another site properly using a feature. Now, you might have noticed there are a few other elements.xml files generated when we did the site export. One stores specific values in the property bag of the list. This we did not want because we don’t really want to copy those internal properties. The other deals with the forms of the list. It uses the BinarySerializedWebPart which scares me a bit, so I haven’t messed with it much. If you are just using default forms you don’t need to worry about it. In a future post, I’ll try seeing if I can deploy some InfoPath forms along with the list, but I figured that deserves its own post.

Also, one other thing to note. If you are deploying your external content type to another server, you can do that in the same manner as you did in SharePoint 2007. Just export the application definition and import it on the new server. You can also use the Export Application Model button in SharePoint designer on the External Content Types list.

I hope this helps when you look to move lists into production. This technique of exporting and importing will also work with regular lists of course. Just remember, friends don’t let friends deploy lists without a feature.

Using the PropertyBag element to assign properties to Items in SharePoint 2010

CoreyRoth — Thu, 11 Feb 2010 21:43:28 GMT

When the NDA dropped, I mentioned how you could use the new PropertyBag element in a feature to write values into the property bag of a site. I already thought that was going to be incredibly useful, but it turns out the power of this new element is even greater than I first realized. At the time I noticed that the PropertyBag element had a Url attribute but I didn’t understand what it was used for at the time. Now I do. As I mentioned yesterday, I have been experimenting with exporting sites as .wsp files and I discovered that you can use this to write to properties of an existing list item. Take a look at the following example, that I grabbed from the file it generated when exporting my site. This applies properties to default.master.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <PropertyBag Url="_catalogs/masterpage/default.master" ParentType="File" RootWebOnly="FALSE" HyperlinkBaseUrl="http://sp2010/Test" xmlns="http://schemas.microsoft.com/sharepoint/">
    <Property Name="vti_charset" Value="utf-8" />
    <Property Name="vti_candeleteversion" Value="true" />
    <Property Name="vti_modifiedby" Value="SHAREPOINT\system" />
    <Property Name="vti_cachedneedsrewrite" Value="false" />
    <Property Name="vti_level" Value="1" />
    <Property Name="vti_rtag" Value="rt:7CDE768C-FCE1-46E8-9165-FDA564419D9A@00000000002" />
    <Property Name="vti_cachedbodystyle" Value="&lt;body scroll=&quot;yes&quot; onload=&quot;BLOCKED SCRIPTif (typeof(_spBodyOnLoadWrapper) != 'undefined') _spBodyOnLoadWrapper();&quot;&gt;" />
    <Property Name="vti_title" Value="&lt;asp:ContentPlaceHolder id=&quot;PlaceHolderPageTitle&quot; runat=&quot;server&quot;/&gt;" />
    <Property Name="UIVersion" Value="3" />
    <Property Name="vti_parserversion" Value="14.0.0.4536" />
    <Property Name="vti_cachedhastheme" Value="false" />
    <Property Name="vti_foldersubfolderitemcount" Value="0" />
    <Property Name="vti_hasdefaultcontent" Value="true" />
    <Property Name="vti_setuppathversion" Value="4" />
    <Property Name="vti_metainfoversion" Value="2" />
    <Property Name="vti_canmaybeedit" Value="true" />
    <Property Name="vti_generator" Value="Microsoft SharePoint" />
    <Property Name="vti_etag" Value="&quot;{7CDE768C-FCE1-46E8-9165-FDA564419D9A},2&quot;" />
    <Property Name="vti_cachedtitle" Value="&lt;asp:ContentPlaceHolder id=&quot;PlaceHolderPageTitle&quot; runat=&quot;server&quot;/&gt;" />
    <Property Name="vti_contentversion" Value="0" />
    <Property Name="vti_progid" Value="SharePoint.WebPartPage.Document" />
    <Property Name="vti_timelastmodified" Value="2010-02-10T16:12:34Z" />
    <Property Name="vti_sourcecontrolversion" Value="V1.0" />
    <Property Name="vti_timecreated" Value="2010-02-10T16:12:34Z" />
    <Property Name="vti_folderitemcount" Value="0" />
    <Property Name="vti_docstoretype" Value="0" />
    <Property Name="ContentTypeId" Value="0x01010500CE60EDAC92E8C942BFB82AF8AFC4A5F4" />
    <Property Name="vti_filesize" Value="29039" />
    <Property Name="vti_sourcecontrolcookie" Value="fp_internal" />
    <Property Name="vti_author" Value="SHAREPOINT\system" />
    <Property Name="vti_setuppath" Value="global\default.master" />
    <Property Name="vti_metatags" Value="GENERATOR Microsoft\ SharePoint progid SharePoint.WebPartPage.Document HTTP-EQUIV=Content-Type text/html;\ charset=utf-8 HTTP-EQUIV=Expires 0" />
    <Property Name="vti_replid" Value="rid:{7CDE768C-FCE1-46E8-9165-FDA564419D9A}" />
    <Property Name="vti_docstoreversion" Value="2" />
    <Property Name="vti_cachedcustomprops" Value="vti_title" />
  </PropertyBag>
</Elements>

As you can see the relative URL of the file is specified along with a separate attribute indicating the base URL it came from. You also need to specify something for ParentType. For now I know that you can specify File or Folder there (although I am guessing it might take Item or something like that).

Now for the most part all of these properties listed above are internal properties that you would never care about setting, but as you guessed you can specify your own properties as well. The export site as template functionality does its best to export everything it can and that includes internal properties as well. This is pretty interesting feature and I think it could remove the need to write a lot of code in my future. @SPKyle might still want to write code to store properties on list items, but I will take a pass. :)

Enabling Content Approval on a List using CAML

CoreyRoth — Thu, 08 Oct 2009 22:16:42 GMT

I’ve always liked the power of CAML because it allows me to create so much in SharePoint without ever having to write a line of code. However, there really isn’t enough examples out there, so I like writing posts like these that focus on doing something very specific with a list. @SPKyle would say just write some code to do that, but that’s not my style, so I did some digging through the SDK and some experimentation and I figured out how to do it. Of course there isn’t an attribute called EnableContentApproval. So, the first thing we have to figure out is what CAML calls content approval. It turns out CAML refers to this as moderation. We’ll add this to the SharePoint UI to API translation guide. Looking at the List element, I find two attributes ModeratedList and ModeratedType. The description of the both is quite similar, so I decide to try them out one at a time. I find that setting ModeratedList works but setting ModeratedType does nothing. No idea why there is two attributes. Maybe one is deprecated. Here is what a List element line would like in your schema.xml.

<List xmlns="http://schemas.microsoft.com/sharepoint/" BaseType="0" DisableAttachments="True" EnableContentTypes="True" Name="MyList" OrderedList="False" QuickLaunchUrl="True" Title="My List" Type="10001" VersioningEnabled="False" Url="Lists/MyList" Id="ed65344b-0399-4c34-8265-de0c2d193165" ModeratedList="TRUE">

I then go take a look at the list versioning settings of my newly created list, and everything looks good. Note, if you want to turn on versioning, you can use the VersioningEnabled attribute that you see above.

Again, I set the ModeratedList attribute in the List element of the Schema.xml. Before I set it on the schema.xml file, I noticed that the ListTemplate element that you use in your elements.xml file had an attribute EnableModeration. The SDK states this can be used to turn on moderation as well. However, when using it I find that it does not work. If I set it to true or false it does not work and does not seem to override I set in the schema.xml file. Anyhow, if you ever need to turn on content approval and don’t feel like writing code, I hope this helps.

Error: Reference to undeclared namespace: ‘ns1’ when trying to create a custom Document Information Panel

CoreyRoth — Tue, 29 Sep 2009 21:40:31 GMT

I’ve been chasing this particular error for a little while and thought I would take the time to share my experience and how to resolve it. The scenario I had is I have a custom content type with several custom site columns. I generated the CAML for my content type and site columns using SPSource. When I clicked on the Create a new custom template button, I received the following error (or one similar).

propertySchema0.xsd#/schema/element[1][@name = 'properties']/complexType[1]/sequence[1]/element[1][@name = 'documentManagement']/complexType[1]/all[1]/element[1]

Reference to undeclared namespace prefix: 'ns1'.

As with all InfoPath errors, this is completely useless. After many attempts at trying to figure out this issue, I noticed that I could create a new Lookup Column and a new Content Type using the SharePoint UI and not receive this error. I then busted out the Imtech Fields Explorer and as far as I could tell all of the properties were just about the same. However, I noticed one difference in the SchemaXML property. My Field element did not have a SourceId but the column created through the UI did. It’s value was set to the Id of the web hosting the site column. I knew I couldn’t set it to that and so I remembered in the past I had always set the SourceId of the field element as seen below.

SourceID=”http://schemas.microsoft.com/sharepoint/v3”

This got me closer, the content types and site columns deployed correctly and the SchemaXML had a SourceID in it. However, when I tried to create a Document Information Panel this time, I got this new lovely error.

InfoPath has encountered an error. The operation failed.

Catastrophic failure

Once again, thanks InfoPath team for such useful error information. After further investigation, I discovered I needed to set the StaticName attribute as well. I simply set this to match the Name attribute I had and everything works now. It’s strange how the content type can work completely everywhere else, but in InfoPath it’s very picky. Here is what a complete working Field element might look like for you.

<Field Type="Text" DisplayName="MyField" Required="FALSE" MaxLength="255" Group="My Field Group" ID="{2E6858a5-6ae2-409f-8492-fa15c39821c8}" Name="MyField" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="MyField" />

I mentioned above the issue I had was with a Lookup column but I quickly discovered that this was happening with all of my columns and had nothing to do with the lookup. SPSource has saved me a ton of time, but this is just another minor thing to look out with the tool. I logged an issue on CodePlex to see if we can get these two attributes added to the Site Column export. If you aren’t customizing Document Information Panels, then there is nothing to worry about with the exported CAML, but if you are be sure and add these two attributes.

Using CAML to deploy a lookup column via Feature

CoreyRoth — Wed, 02 Sep 2009 21:47:49 GMT

This week, I needed to deploy lookup columns to some of my lists and as usual I wanted to avoid writing code at all costs. As some of you may know, Kyle Kelin and I debate this topic often as he prefers a code approach. I figured it had to be possible with CAML, but many claimed it was not even possible. A few approaches showed up out there involving using code to modify the elements.xml file with your GUID, but that just wasn’t going to cut it for me. One popular post on the topic by Josh Gaffey, started me in the right direction, but there were a few hurdles I ran into as I was trying to implement it. It would create the list, show the content type, and site columns, but when I tried to create a new item, the lookup column was not there. The basic technique is that you specify the path to the list in the form of (Lists/MyListName) in the List attribute of the Field element in both your schema.xml file of your document library template as well as the definition of the site column. The first thing I learned here is that you cannot simply omit declaring site columns and a content type out and go with list level columns. It simply will not work (no idea why).

Here is how I ended up getting everything to work. I created my initial lists, content types, and site columns through the SharePoint UI. I then used SPSource (seriously a great tool) to export the content type, site columns, and lists (both the source list and the one that contained the lookup column). My goal was to deploy these items to another site collection. I recommend creating separate features for your content types and the list definition. This way you can ensure the content type is deployed first. To export your content type / site columns, create a new stub feature.xml file as described on their site and then create an .spsource file with just the content type in it like this (no need to specify columns).

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ContentType Name="Test" />
</Elements>

In my example, my content type was called Test. Create a separate feature folder for your list template and instance. Create another feature.xml and an .spsource file for the list which looks something like this. My list is also named Test in this case.

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ListTemplate Name="Test" />
</Elements>

SPSource does a good job when it exports my list definition and properly specifies the list using a path instead of a guid in my lookup column as shown below (from schema.xml).

<Field Type="Lookup" DisplayName="DocumentCategory" Required="FALSE" List="Lists/Categories" ShowField="Title" UnlimitedLengthInDocumentLibrary="FALSE" Group="My Group" ID="{9266e0fa-ae49-438c-acdc-73063684ac8f}" SourceID="{50b253e5-e90e-4781-8fce-cece417b185e}" StaticName="DocumentCategory" Name="DocumentCategory" Customization="" ColName="int1" RowOrdinal="0" />

We don’t actually have to change a thing in this file. What I did have to change is the List attribute of the file it generated for my site columns. As Josh’s post above stated, we have to change the List attribute from a GUID to the path of the list. His post also mentioned you might want to set the PrependId attribute but I have since learned that this is only used when you are using the LookupMulti type (although I can’t remember the source I got this from).

<Field Type="Lookup" DisplayName="DocumentCategory" Required="TRUE" List="Lists/Categories" ShowField="Title" UnlimitedLengthInDocumentLibrary="FALSE" Group="My Group" ID="{9266e0fa-ae49-438c-acdc-73063684ac8f}" Name="DocumentCategory" />

At this point you can deploy your site columns, content type, and then custom list (in that order) and if all goes well you will be able to create a new item of that content type with the lookup column functioning. One thing to note, if you get this wrong, your list will behave oddly. One thing I noticed is that it won’t turn on content types for the list when that happens. If this is happening go back and check your work. Another thing people mentioned is that the source list for the lookup column has to exist before you create the lookup column. This in fact is not true. It will work and it will display a drop down list for the lookup column, but it will be empty of course since the list does not exist.

Along the way I figured out a few other things. When I was trying to figure this out, I was trying to just create the content type and then manually add it to the list via the UI. Doesn’t work. If you try to add a content type with a lookup column defined in this way to an existing list, you will get the following error.

Exception from HRESULT: 0x80040E07 at Microsoft.SharePoint.Library.SPRequestInternalClass.AddField(String bstrUrl, String bstrListName, String bstrSchemaXml, Int32 grfAdd)
at Microsoft.SharePoint.Library.SPRequest.AddField(String bstrUrl, String bstrListName, String bstrSchemaXml, Int32 grfAdd)

The only way to get the content type associated with the list is via CAML when it is created. Another odd thing is that the lookup column never shows it is bound to the other list correctly. Here is what the source lookup column looked like.

Notice where it says Get information from, the name of the list is present. Here is what my copy of the list looks like.

Notice that the list name is not present. Strangely enough though, everything works fine in the copy. This one through me for a loop for a while because it didn’t seem like things weren’t working and as I mentioned above I couldn’t add the content type to a list (nor could I add the column to a content type).

As you can see there are few oddities about deploying lookup columns in this manner, but it does work. @SPKyle informed me he could have written code to do this hours ago, but I am quite happy that I can deploy things in this manner now.

Twitter: @coreyroth

My First Experience with SPSource

CoreyRoth — Mon, 04 May 2009 16:45:36 GMT

If you pay attention to twitter at all, today you might have heard about a new tool on CodePlex called SPSource. SPSource is a tool that reverse engineers existing Content Types, Site Columns, Lists and more on an existing SharePoint site. This isn’t just a re-tweet style post that tells you its out there. I actually took a few minutes today to try it out and so far I am very impressed. Kyle Kelin and I have often talked about the need for a better tool that worked better than VSeWSS Solution Generator. Already, I think this tool is it. Finally you can design a content type in the UI and be able to extract it easily as a feature.

Downloading the tool from CodePlex, gives you an installer for the SPSource executable. The tool is a command line app designed to be executed in a batch file. To get started with the tool, you need to create a local 12 hive folder. You can do this inside Visual Studio manually or with a tool like wspbuilder. For my test purposes, I just created a 12 hive folder in a temp directory and started working. Before you begin, you will need to create a folder to hold your feature as well as a simple feature.xml file. The contents of the file don’t need to contain much, just some XML for deploying a simple feature. The next thing you need to do is identify what you want to extract from your SharePoint. In my case I wanted to extract some content types and a list template. You then create a special XML file with the .spsource extension. This uses the same syntax as any elements.xml file, but it is used to specify which items to extract from SharePoint. The only thing you need to specify is an element such as ContentType or ListTemplate and the name. It then uses this name to look up the resource in SharePoint and extract it. Here is an example of what it looks like.

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ContentType Name="My Test Content Type" />
  <ListTemplate Name="My Custom List" />
</Elements>

SPSource will take this information and generate the XML files I need to deploy these items elsewhere. You run SPSource with the following syntax.

spsource.exe –designsite http://my-moss-server/site

When the tool is executed, it will iterate through any subfolders looking for .spsource files. When it finds them, it will create XML files representing the type of items you request (in my case a ContentType and a ListTemplate). It will also update the Feature.xml file in that folder to point to any new .XML files it creates. So far I have found the XML it generates to be very usable and way more accurate than what SPSolGen gives you.

This tool is really nice. I would like to see some more documentation for it, but I am sure that will come as the tool is developed more. When you first install it, all you are given is a link to the CodePlex site in your start menu, so you are left a little bit wondering what to do next. I would love to see more command line options such as just passing it a URL and it extracts the list template. One thing I noticed is that it didn’t extract the ItemEventReceivers definition I had on my content type. I am not complaining though since this tool already has the power to save me a ton of time in the future.

Great work @jthake and everyone else that worked on it. Microsoft should have provided a better tool to do this years ago. I am glad you all stepped up to fill in the gap.

Follow me on twitter.