Corey Roth [MVP] : Content Type

A look at content type hubs in SharePoint Online (Office 365)

CoreyRoth — Tue, 21 Feb 2012 02:29:02 GMT

For those of you familiar with SharePoint 2010, the content type hub is nothing new to you. However, in SharePoint Online, the content type hub works a little differently. The first thing to know is that a content type hub has been set up automatically for you. You just have to know where to find it. You can’t get to it from Tenant Administration like you might expect. Instead, you can find the location by going to the Site Settings page of any site collection and then the Content Type Publishing link. You will see a screen like the one below which links directly to the content types of a site collection containing your hub.

From here you will learn that your content type hub is located in a site collection named /sites/contentTypeHub. Clicking on the link from this page will allow you to view the content types in the hub. One issue I have noticed here though is that only the original Office 365 account creator has access to the site collection. Accessing it with another user will get you an access denied error message even if you are a global administrator.

Unfortunately, you cannot fix this yourself from the tenant administration page because this site collection does not show up on the list. This means you need to get the person who created the original Office 365 account to go to this site collection and add you as a site collection administrator. It’s easy to fix but it requires you to involve whomever set up the account to begin with.

Once you get into the content type hub, you can create and publish your desired content types just like you would in SharePoint 2010. When you publish a content type, you should see it in the other site collections within a few minutes.

Working with the content type hub is easy. Try it out with your account today. These examples were demonstrated with an E3 account.

A quick look at the content type editor in Visual Studio 11

CoreyRoth — Mon, 06 Feb 2012 16:52:10 GMT

Visual Studio 11 introduces a new content type editor that you might find useful when building your next content type. It starts with a SharePoint Project Item that you can pick from the New Item menu.

From this screen, give your new content type a name and then you’ll be presented with this next screen allowing you to pick a content type to inherit from. This pulls a list of every content type currently on the site collection that you have your Visual Studio project associated with.

Pick the content type you want to inherit from and you will then see the new content type editor.

From here you can begin adding exiting site columns to your new content type.

Selecting one will bring over the type automatically. Unfortunately the only option you get here is whether the column is required or not. However, you can click on the elements.xml file in the solution explorer to edit the XML directly. I’ve tested and it will preserve any additional attributes you add to your site column references there.

You might be wondering what about site columns that have not been created yet. The editor is actually smart and knows to look at any site columns defined in the same project as well. For example, I created this new site column below.

Unfortunately, creating site columns still requires XML, but Visual Studio at least gets you started. After you save your new site column, you will find the site column in the list.

You can also set some of the common properties such as the group and description of the content type itself by clicking on Common Properties.

What about inheriting from your own content type in the same project? That actually works as well. However, you will have to look for it at the top of the content type list.

That’s a quick look at what Visual Studio offers for content type editing. I think the SharePoint Designer still has a few more features, but the main difference is what you create here can actually be deployed elsewhere. This will work with SharePoint Online as well. Just use the new publish feature I have talked about earlier.

For more information on Visual Studio 11, go to the Developer Preview site.

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

How to: Seal a Content Type

CoreyRoth — Wed, 11 Mar 2009 14:15:58 GMT

Sometimes, you want to make absolutely sure that someone can’t go in and change your content type via the Windows SharePoint Services user interface. If an administrator were to delete or rename columns in your content type this can cause all sorts of issues as things may or may not be prorogated down to the child types. You might also want to ensure that a content type is only created / modified by using a feature and CAML. To solve this, a content type can be marked as sealed and it can only be marked as sealed through the object model. This prevents any casual changes to the content type via the user interface.

The code to seal a content type is pretty simple. Just get a reference to the particular content type you want to change, set Sealed to true and update the content type. In my example, I am just changing a content type off the root of the site collection called Test Content Type. Here is the code.

   14             using (SPSite currentSiteCollection = new SPSite("http://moss-server"))
   15             {
   16                 SPContentType contentType = currentSiteCollection.RootWeb.ContentTypes["Test Content Type"];
   17                 contentType.Sealed = true;
   18                 contentType.Update();
   19             }

Of course there are some things you should know before sealing a content type. As mentioned before, you will not be able to make any changes in the user interface as you can see below. You also have to be a site collection administrator to seal the content type. This means your code has to be executed by a user with appropriate permissions (a console app works fine). You also need to know that sealed content types are not updated through push-down operations. So if a change is made in a SPWeb’s content type and a list’s content type beneath it is sealed, that child content type won’t be updated. You just have to remove all of your seals first.

That is what your content type will look like once it is sealed. This concept also applies to the SPField object (for Site Columns) as well, the code would be quite similar and also makes use of the Sealed property. You can also seal content types at the list level as well. To unseal your content type, just set the sealed property to false and update it again.

A Note on Content Type Inheritance

CoreyRoth — Tue, 04 Nov 2008 17:15:47 GMT

I ran into this issue a while back so I thought I would post on it. I had a scenario where we wanted to create a simple content type to use as a base content type for all future content types at a comapany (i.e.: Company Base Document). At the time we did not know what site columns we wanted included, so we didn't include any FieldRefs to site columns. We just inherited from this type into another more project specific document type. It seemed like a good idea at the time, but it of course caused a number of problems.

It appears that if you do not specify any FieldRef elements in your content type definition that any other fields further up in the inheritance tree will also not get inherited. This caused things like the Title field (inherited from item) to not be included in our content type. The lesson to be learned here is a) plan better and have your fields defined first and b) make sure that you always specify at least one FieldRef in your content type definition. I am sure there is a technical reason for this, but I thought I would throw it out there in case someone else runs into the issue in the future.

Also if you haven't checked out my latest addon for Enterprise Search, go check it out. I am pretty excited about it and the users I have shown it to so far have found a lot of value in it.

How to: Create a Custom Document Library

CoreyRoth — Wed, 11 Jun 2008 13:53:58 GMT

Not too long ago, I talked about how to remove the Explorer View from a document library. As part of the post, I mentioned that I would post how to build a custom document library in the near future. That is what I am covering today. I really don't know what the best practice is on how to create a document library, I am just going to show you how I have done it in the past.

Usually, the way I start is by taking a copy of the existing builtin SharePoint DocumentLibrary feature and add it to a new Visual Studio solution. Typically I would put this in a 12 hive folder (i.e. TEMPLATE\FEATURES). The next step is I rename the DocumentLibrary feature folder (i.e. CustomDocumentLibrary). The next thing you will want to do is edit the Feature.xml file. We have to make some basic changes so that this is considered a new feature. Therefore, you will want to pick a new GUID for the Id and give it a new Title and Description. You may also want to change Hidden to False so that you can activate it and deactivate it through the UI.

Next, we need to edit the ListTemplates/DocumentLibrary.xml file. This file defines the list template itself. The first thing you need to change is the Type. The Type number for a Document Library is 101. It is recommended that user defined list templates start with 10000, so pick any number in that range that isn't used.

The next file you need to modify is the DocLib/Schema.xml file. On the root List element, you will want to change at the minimum the Title element. You may also want to set EnableContentTypes to true if you want to use custom content types. Set FolderCreation to false if you have a custom folder type and set VersioningEnabled to true if you want versioning enabled in the document library. The Url property I believe is the default URL that you document library will use when created. It is specified as a relative path (usually just the folder name). Here is what a typical root list element looks like.

<List xmlns:ows="Microsoft SharePoint" Title="My Custom Document Library" Direction="$Resources:Direction;" Url="My Custom Documents" BaseType="1" xmlns="http://schemas.microsoft.com/sharepoint/" EnableContentTypes="True"  FolderCreation="false" VersioningEnabled="true">

I have been leaving the BaseType attribute set to 1 and things have been working fine. However, I have a feeling that it should probably be set to 101 so that Document Library is the base type. In the MetaData section, you can override the folder and document content types. I discussed how to properly do that in this post. You just need to reference the content types you are using and then also add Field elements for each custom site column you are using in those content types. Again, the post mentioned above describes how to do that. The Scema.xml file is also where you can remove (or create) different views for your document library. This is where you would go to remove the explorer view that I mentioned a while back.

Once you have made these changes, you are ready for deployment. There are other files in the DocLib folder, but I typically don't mess with them. Your custom document library can be deployed by copying out the feature and using stsadm or you can create a solution file for it. Once the feature is activated you are ready to create instances of your new document library. Also note that the Visual Studio Extensions for SharePoint can also create a lot of these files for you, but you will still need to go through and customize your various XML files.

Implementing Metadata Inheritance using an ItemEventReceiver

CoreyRoth — Mon, 19 May 2008 18:59:15 GMT

When implementing an ECM solution, it is often necessary to come up with a way for documents to inherit metadata from a parent folder. The main reason of doing this is so that user's can search on any of the document's properties. Other ECM solutions do this for you (yes there are other ECM solutions other than SharePoint), but WSS requires a bit of code to make it happen. The way you do it is by creating an ItemEventReceiver and then by setting properties in the event handling method of various events. To start out, I am assuming you have created your own content types for a custom folder and document. We'll call these Custom Folder Type and Custom Document Type respectively. I am also assuming you are deploying these via feature. The reason is you need to set up an Item Event Receiver on the Custom Document Type and it is much easier to configure via feature.

The first thing we need to do is create the class to contain the event handling methods of the ItemAdded, ItemUpdated, and ItemCheckedIn events (there are more event types, but these are the only ones we need). I recommend putting this class in its own library (or in a library with other item event handling methods). My reason for this is that I have only been able to get an item event handling method to fire is when the assembly is in the GAC. If you have read my blog in the past, you know I almost always recommend against this, but in this case, I don't know of any choice. To implement the class, start by having your custom class inherit from SPItemEventReceiver. You can then override various event handling methods. In this case, I want to enforce the metadata inheritance whenever a document is added, updated, or checked in. To do this, we override the ItemAdded, ItemUpdated, and ItemCheckedIn methods. The contents of all the methods is typically the same. They call a method to do the inheritance and if it fails, we attempt to cancel the event (although I have never had it cancel anything when there is an exception).

public override void ItemAdded(SPItemEventProperties properties)
{
    base.ItemAdded(properties);    
 
    try
    {
        InheritCustomProperties(properties.ListItem);
    }
    catch (Exception e)
    {
        properties.Cancel = true;
        properties.ErrorMessage = "Error inheriting metadata.";
        properties.Status = SPEventReceiverStatus.CancelWithError;
    }
}

The SPItemEventProperties allows you to get access to the list item using the ListItem property. We then pass it to our custom method which does the inheritance. In this example, I am assuming that the parent folder has two properties: Product Id and Color, that we want to copy into the newly added (or updated) item.

protected void InheritCustomProperties(SPListItem childItem)
{
    // make sure that the parentFolder and its item are not null
    if ((childItem.File.ParentFolder != null) && (childItem.File.ParentFolder.Item != null))
    {
        SPItem parentItem = childItem.File.ParentFolder.Item;
 
        // copy properties from parent to child
        childItem["Product Id"] = parentItem["Product Id"];
        childItem["Color"] = parentItem["Color"];
 
        // event firing must be disabled otherwise this update will cause another event to fire
        DisableEventFiring();
        childItem.SystemUpdate(false);
        EnableEventFiring();
    }
}

One thing to make sure is that a parent item exists for you to inherit from (obviously you would need to do something different if you were uploading documents to the root of a library). Next it is just a matter of getting a reference to the parent item and then start copying each property. Before updating the child item, you need to make a call to the base class's DisableEventFiring method to keep it from firing an event when you save the item. Next, you should call SystemUpdate instead of Update which will save the item but not save it as a new version.

That is all the code that is involved. However, you still need to modify the XML of your Content Type feature to tell it to use your even receiver. In your content type's Elements.xml file, you'll need to add some new entries to the XmlDocuments element (add one if you don't have one already). Then, add a section similar to the one below to your file. You will see one receiver for each event type (ItemAdded, ItemUpdated, ItemCheckedIn).

<XmlDocument NamespaceURI="http://schemas.microsoft.com/sharepoint/events">
  <spe:Receivers xmlns:spe="http://schemas.microsoft.com/sharepoint/events">
    <Receiver>
      <Name>Custom Document Added Event Handler</Name>
      <Type>ItemAdded</Type>
      <SequenceNumber>10001</SequenceNumber>
      <Assembly>CustomEventReceivers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f2d79125eb887b9e</Assembly>
      <Class>CustomEventReceivers.CustomDocumentLibraryItemEventReceiver</Class>
      <Data />
      <Filter />
    </Receiver>
    <Receiver>
      <Name>Custom Document Updated Event Handler</Name>
      <Type>ItemUpdated</Type>
      <SequenceNumber>10001</SequenceNumber>
      <Assembly>CustomEventReceivers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f2d79125eb887b9e</Assembly>
      <Class>CustomEventReceivers.CustomDocumentLibraryItemEventReceiver</Class>
      <Data />
      <Filter />
    </Receiver>
    <Receiver>
      <Name>Custom Document Check In Event Handler</Name>
      <Type>ItemCheckedIn</Type>
      <SequenceNumber>10001</SequenceNumber>
      <Assembly>CustomEventReceivers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f2d79125eb887b9e</Assembly>
      <Class>CustomEventReceivers.CustomDocumentLibraryItemEventReceiver</Class>
      <Data />
      <Filter />
    </Receiver>
  </spe:Receivers>
</XmlDocument>

The SequenceNumber is the order in which your event handling method fires. Microsoft typically recommends something starting with 10,000 and above to avoid conflicts with their event handlers. The Assembly element, takes a standard assembly reference to a DLL in the GAC. The Class element specifies the namespace and class which contains the event handling methods.

Again, I recommend keeping the feature for your content type and your event receivers in different assemblies. Install your assemblies first with a solution package. Then you can install the feature containing your updated content type. Once you have it installed, add some metadata to a parent item, save it, and then try uploading a new document to verify that the metadata was copied to the new document. If the event handler threw an exception, most likely it did not display a visible error. Unfortunately, this means you'll have to do some GAC debugging. It sounds like quite a bit of work, but it really isn't bad.

Creating a Content Type based Folder in SharePoint via Feature Receiver

C-Dog's .NET Tip of the Day — Mon, 14 Jan 2008 21:40:06 GMT

I have been working a lot with document libraries again and in this particular implementation, I had a need to create a pre-determined set of folders upon document library creation that were based upon a custom content type. I couldn't find a way...(read more)