Corey Roth [MVP] : Document Library

Determining the most popular items in a document library in SharePoint 2013

CoreyRoth — Thu, 28 Mar 2013 19:39:39 GMT

With the combination of analytics and search in SharePoint 2013, there is a heap of new features to help determine which content is actually being used. No longer is this information buried in reports for administrators, but it in fact is available right from the ribbon in a document library. Maybe you have even noticed the Most Popular Items button in the ribbon already. You can find it on the library tab in the middle.

Click on it and you will be taken to a custom search results screen that shows you recent views and total views.

What’s nice is that you can even search and refine within the report if you are looking for something specific. You can also click on the Popularity Trends link to get a nice graph of the usage of the file over time.

Behind the scenes, this report is powered by the Popular result source. You can also use this source to look for popular items across your entire index. As a developer, the possibilities are quite interesting.

My particular tenant doesn’t have a ton of usage, but if you’re already running SharePoint 2013 you might be able to extract some valuable insights from this report. Try it out today.

SharePoint Workspace Error: Data in this list references content type "", which is no longer in the list schema

CoreyRoth — Mon, 16 May 2011 20:10:27 GMT

My team and I have come to rely on SharePoint Workspace for our current project on a daily basis. Most of us never even open a web browser even and browse project documents solely by using SharePoint Workspace. It’s a great tool and allows us to grab a copy of the latest documents and view them offline on the airplane or wherever. Leave it up to us to also find a way to break it. Back in April our world came crashing to a halt when all of the sudden, SharePoint Workspace would no longer sync our document library. When trying to sync we were met with the following error. Here is what you saw when you click on Resolve in the ribbon.

Data in this list references content type "", which is no longer in the list schema.

Doing a quick search on the Internet quickly yielded nothing. In our case, no changes to the document library occurred. The schema was the same and the only thing new was that documents were uploaded on a daily basis. I tried various things but could not come up with a solution. I finally relented and burned one of my MSDN subscription support incidents. The support engineer, Patrick Gan, immediately suspected OneNote. We have used OneNote pretty heavily on this project. He did some testing on his end and eventually he was able to reproduce the problem. As a result, I moved all of my OneNote files out of the library and tried to synchronize again and sure enough the issue went away.

Now, it turns out, not all OneNote files cause the issue. Individual .one files are fine. There are also OneNote files with an extension of .onetoc2, .onebin and .onepkg. I believe it to be one of these two file extensions that causes the problem but never narrowed down which one. It appears that when you make use of the File –> Share menu in OneNote when it published your notes to a document library these files get created and the synchronization errors occur. The support engineer also mentioned that OneNote creates folders when you share this way that may be the cause of the issue. In those folders is where the .onebin file is stored so that may be the case.

Another workaround that I have received is to open the offending notebook in OneNote, click the File tab and then click View Sync Status. From there, click on Work Offline. This will prevent OneNote from resyncing files to that particular library. I created a new document library for now that just has my OneNote files in it. I then used the Change Location button to choose the new document library. At this point, you may need to go in and clean up the unwanted .one* files in the previous document library. It should sync at this point, but if it doesn’t, disconnect the existing library from the workspace and recreate it and it should work.

If you receive the above issue, hopefully one of the stated workarounds will resolve your issue. On the bright side, this is classified as an official bug and there will be a fix “in the very near future” (whatever that means). Until a fix is available, try these workarounds. Thanks to Patrick once again for assisting us in resolving the issue.

Spice up your ECM with Ratings in SharePoint 2010!

CoreyRoth — Mon, 22 Nov 2010 16:23:34 GMT

At Tulsa TechFest, I gave a talk about the various new ECM features available out of the box in SharePoint 2010. One feature of particular interest to the crowd was average ratings. I had lots of questions on it so I thought it was worth a blog post. Instead of describing it first, let’s start with a picture.

As you can see in the above picture, ratings are a new field available which gives users the ability to rate each document using stars just like they might do in iTunes or any other application. Behind the scenes, it takes the ratings of each user and a timer job comes along periodically and calculates the average rating. This allows users to quickly determine which documents are the most popular when viewing a document library. You can also sort on this field as well. It’s easy to add to both your document libraries and content types.

In reality, Ratings are nothing more than a site column, but SharePoint 2010 makes it really easy to add them to an existing document library. Just click on Library Settings in the ribbon and then Ratings settings.

One you do that, two new site columns are added to your document library, Rating (0-5) and Number of Ratings. The Rating (0-5) site column, named AverageRating internally, is the column users interact with. Users can’t edit the Number of Ratings column, named RatingCount internally. The timer job just uses it to help calculate the average.

At this point, your users can start rating documents. It’s that simple. When you view the properties on a document, you will see the average rating and the number of ratings as well.

In reality, you can actually just add the above two site columns to any list or content type and have ratings work. I have actually started including these in my base content type on most ECM deployments. This is a content type that I use in lieu of the Document content type which has additional site columns. All other content types I create will inherit from this one. It adds great functionality to every content type that inherits from it. If some people don’t like the ratings on their documents, they can always just remove it from the view on his or her document library.

To add the columns to a content type, just click the Add from existing site columns link on your content type page. You will find the two columns listed in the Ratings Group. You will want to add both of them to your content type.

When you add one of these columns, you will get a warning stating that some earlier versions of Office cannot use these fields. If you are using Office 2007 or earlier, you may want to test this out some to see if it will be an issue in your organization.

Once you click OK, your content type is ready for use. Now, I would be a bad blogger if I didn’t show you how to add these fields using CAML. If you want to add these two fields to a content type, just add the following elements to the FieldRefs element.

<FieldRef ID="{5a14d1ab-1513-48c7-97b3-657a5ba6c742}" Name="AverageRating" />
<FieldRef ID="{b1996002-9167-45e5-a4df-b2c41c6723c7}" Name="RatingCount" />

Since these fields are included out-of-the-box, I believe those GUIDs should always be the same. If I’m wrong, someone let me know. You can also add these fields to document libraries as well. Just add the following Field elements to the Fields element in your schema.xml.

<Field ID="{5a14d1ab-1513-48c7-97b3-657a5ba6c742}" Name="AverageRating" StaticName="AverageRating" DisplayName="Rating (0-5)" Description="Average value of all the ratings that have been submitted" Group="Ratings" Type="AverageRating" Decimals="2" Min="0" Max="5" ShowInEditForm="TRUE" ShowInDisplayForm="TRUE" ShowInNewForm="FALSE" SourceID="http://schemas.microsoft.com/sharepoint/v3" RowOrdinal="0" />
<Field ID="{b1996002-9167-45e5-a4df-b2c41c6723c7}" Name="RatingCount" StaticName="RatingCount" DisplayName="Number of Ratings" Description="Number of ratings submitted" Group="Ratings" Type="RatingCount" Min="0" Decimals="0" ShowInEditForm="FALSE" ShowInDisplayForm="TRUE" ShowInNewForm="FALSE" SourceID="http://schemas.microsoft.com/sharepoint/v3" RowOrdinal="0" />

Try out document ratings today. They provide a lot of functionality and are quite easy to implement.

Files uploaded to the wrong folder in a document library

CoreyRoth — Wed, 10 Mar 2010 16:30:56 GMT

This is kind of a weird one so I thought it was definitely worth posting. Recently we were doing some integration testing where an external application was linking directly to specific folders. The users would then upload a document in that folder and then they could not find their file. Where was the file? Well it was sitting in the root folder for some reason. Consider the following URL that was being used.

http://moss-server/MySiteCollection/MySite/DocumentLibrary/SubFolder

This can also be expressed like this using the RootFolder parameter.

http://moss-server/MySiteCollection/MySite/DocumentLibrary/Allitems.aspx?RootFolder=/MySiteCollection/MySite/DocumentLibrary/SubFolder

The application linking to us was using a path very similar to the ones above. However, when the user tried to upload the file after coming from that external application, the file they uploaded would be sitting in the root folder every time. It was strange because, the user was in the correct folder when they followed the link, but when they clicked Upload I noticed the breadcrumb did not have the subfolder listed in it. When I tried browsing to the folder in SharePoint and uploading it worked correctly. Something strange was definitely going on. I started examining everything and I took a look at the link they were using to get to us. Here is what they were using.

http://moss-server/mysitecollection/mysite/documentlibrary/subfolder

Notice the difference? Exactly, the URL they were using was all lower case. I thought surely case sensitivity wouldn’t be the cause. I corrected the case in the application and sure enough files started going into the correct folder. I couldn’t find anything on the internet about this at all until I discovered the case sensitivity and found this post that confirmed a similar issue. If you don’t believe me, go to any document library on your server and try changing the case and see what happens. :)

What it comes down is that the case matters in the URL on everything after the server name. I created the site collection as MySiteCollection (ok no I really don’t have a site collection named this, but this is an example :) ), so that means any time you have a URL the case better match. The problem is you might not remember how you set the case up when you created the site, site collection, or document library. If you don’t there is an easy way to figure it out, just browse to the subfolder you want and copy the URL from your browser. If you URL decode the RootFolder querystring parameter you will see the casing that should be used. I hope this helps in case you happen to run into it.

Specifying a list by name in a .UDCX file

CoreyRoth — Mon, 05 Oct 2009 21:07:08 GMT

I’ve been working with InfoPath again lately since I’ve been working with Document Information Panels and I thought I would share another quick tip today. Observe the following .UDCX file.

<?xml version="1.0" encoding="UTF-8"?>

<?MicrosoftWindowsSharePointServices ContentTypeID="0x010100B4CBD48E029A4ad8B62CB0E41868F2BF"?>

<udc:DataSource MajorVersion="2" MinorVersion="0" xmlns:udc="http://schemas.microsoft.com/office/infopath/2006/udc">

<udc:Name>list_2F9fb67e-ab7d-44b7-accc-d9f6c9ca37f9</udc:Name>

<udc:Description>Format: UDC V2; Connection Type: SharePointList; Purpose: ReadOnly; Generated by Microsoft Office InfoPath 2007 on 2009-10-05 at 15:02:14 by MOSS-SERVER\moss_setup.</udc:Description>

<udc:Type MajorVersion="2" MinorVersion="0" Type="SharePointList">

<udc:SubType MajorVersion="0" MinorVersion="0" Type=""/>

</udc:Type>

<udc:ConnectionInfo Purpose="ReadOnly" AltDataSource="">

<udc:WsdlUrl/>

<udc:SelectCommand>

<udc:ListId>2F9fb67e-ab7d-44b7-accc-d9f6c9ca37f9</udc:ListId>

<udc:WebUrl>http://moss-server/MySiteCollection/</udc:WebUrl>

<udc:ConnectionString/>

<udc:ServiceUrl UseFormsServiceProxy="false"/>

<udc:SoapAction/>

<udc:Query/>

</udc:SelectCommand>

<udc:UpdateCommand>

<udc:ServiceUrl UseFormsServiceProxy="false"/>

<udc:SoapAction/>

<udc:Submit/>

<udc:FileName>Specify a filename or formula</udc:FileName>

<udc:FolderName AllowOverwrite=""/>

</udc:UpdateCommand>

</udc:ConnectionInfo>

</udc:DataSource>

I generated this .UDCX file with InfoPath using the Convert button on the Data Sources form. As you can see from the ListId element is conveniently hard coded with the GUID of a list. That makes this .UDCX file absolutely worthless when deployed to a new server. I looked for some documentation .UDCX to see if I could put a path in for the ListId, but I couldn’t find anything that stated I could. I tried the path (i.e.: Lists/MyCustomList) and I got a list not found error when I tried to open the form. So I then decided to just specify the list by its name and sure enough it works. Here is what it looks like.

<?xml version="1.0" encoding="UTF-8"?>

<?MicrosoftWindowsSharePointServices ContentTypeID="0x010100B4CBD48E029A4ad8B62CB0E41868F2BF"?>

<udc:DataSource MajorVersion="2" MinorVersion="0" xmlns:udc="http://schemas.microsoft.com/office/infopath/2006/udc">

<udc:Name>list_2f9fb67e-ab7d-44b7-accc-d9f6c9ca37f9</udc:Name>

<udc:Type MajorVersion="2" MinorVersion="0" Type="SharePointList">

<udc:SubType MajorVersion="0" MinorVersion="0" Type=""/>

</udc:Type>

<udc:ConnectionInfo Purpose="ReadOnly" AltDataSource="">

<udc:WsdlUrl/>

<udc:SelectCommand>

<udc:ListId>MyCustomList</udc:ListId>

<udc:WebUrl>http://moss-server/MySiteCollection/</udc:WebUrl>

<udc:ConnectionString/>

<udc:ServiceUrl UseFormsServiceProxy="false"/>

<udc:SoapAction/>

<udc:Query/>

</udc:SelectCommand>

<udc:UpdateCommand>

<udc:ServiceUrl UseFormsServiceProxy="false"/>

<udc:SoapAction/>

<udc:Submit/>

<udc:FileName>Specify a filename or formula</udc:FileName>

<udc:FolderName AllowOverwrite=""/>

</udc:UpdateCommand>

</udc:ConnectionInfo>

</udc:DataSource>

As you can see I just specified the name of my custom list and it works great. I still have to update the WebUrl when I put this on a new server, but this eliminates the hassle of having to look up and deal with list Ids.

Watch out for TemplateType when using SPSource to export lists

CoreyRoth — Mon, 21 Sep 2009 14:55:27 GMT

I can’t continue to reiterate how much time SPSource can save you when it comes to exporting existing lists into usable features, but I found one minor thing to look out for when you are exporting lists. Usually, you can take just about whatever SPSource gives you and redeploy it without having to change a thing, however in the cases of lists you need to look out for the TemplateType attribute otherwise it can cause you problems. Take a look at the XML below from the elements file.

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

<ListTemplate AllowDeletion="True" AllowEveryoneViewItems="False" BaseType="1" DisplayName="Concepts" Description="" EnableModeration="False" Hidden="False" OnQuickLaunch="True" Name="List1" Type="100" SecurityBits="11" Sequence="110" DocumentTemplate="101" VersioningEnabled="True" />

<ListInstance FeatureId="cac9f905-9380-4252-8307-d2cffb6f0c1f" Id="c5dd284f-fb59-44b9-bcfd-b4f779d9fd8d" TemplateType="100" Title="List1" Url="Lists/Lists1" />

<ListTemplate AllowDeletion="True" AllowEveryoneViewItems="False" BaseType="1" DisplayName="Regionals" Description="" EnableModeration="False" Hidden="False" OnQuickLaunch="True" Name="Regionals" Type="101" SecurityBits="11" Sequence="110" DocumentTemplate="101" VersioningEnabled="True" />

<ListInstance FeatureId="cac9f905-9380-4252-8307-d2cffb6f0c1f" Id="631657f0-b687-4b61-ad28-13ea1140cd21" TemplateType="101" Title="List2" Url="Lists/List2" />

</Elements>

As you can see I have a ListTemplate and ListElement element for two different lists (list1 and list2). If you look further you notice that the Type attribute on the ListTemplate elements is 100 and 101 respectively. The issue is that 100 is already reserved for a generic list and 101 is a document library so deploying this file can cause general weirdness in SharePoint. Here is the list of stock list template IDs in case you were curious.

As you may guess this is pretty easy to resolve. Just pick a new number that is not reserved for your Type. I believe the best practice recommends starting at 10000. After you change the Type attribute, be sure and change the TemplateType attribute of the ListInstance element to match it. That is all there is to it. If you haven’t checked out SPSource yet be sure to, the next time you need to export sites, lists, content types or site columns. It can save you a ton of time.

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.

How to: Remove the Explorer View from a Document Library Template

CoreyRoth — Thu, 29 May 2008 18:40:30 GMT

If you are building a custom document library solution, there may be a time where you don't want users to use the Explorer View of the document library. I am talking about the view itself and not the Open with Windows Explorer action in this case. The correct way to do is of course is to create your own custom document library template (I'll be covering that in a future post) and then modify the schema.xml file. If you want to go crazy and unsupported, you can also modify the schema.xml of the built-in DocumentLibrary feature and accomplish the same result for the out-out-the-box document library. Removing it is just a matter of removing the appropriate View element in the schema.xml file. In this case, you are looking for an element similar to the one below.

<View BaseViewID="3" Type="HTML" WebPartZoneID="Main" DisplayName="$Resources:core,Explorer_View;" Url="Forms/WebFldr.aspx" SetupPath="pages\webfldr.aspx" RequiresClientIntegration="TRUE" ReadOnly="TRUE">

It will have a BaseViewId of 3 and a Display Name indicating that it is the explorer view. Just delete this entire View element and reactivate the feature and this view will not be present on any new document libraries you create. Again, I recommend creating your own document library template instead of modifying the built-in one. I'll cover this soon, since I haven't found too many good sets of instructions out there on how to do it.

How I used LINQ to XML to Create Document Library Folders

C-Dog's .NET Tip of the Day — Thu, 17 Jan 2008 23:29:24 GMT

I have been doing a lot of document library work lately and in my work I had a need to create a series of subfolders in the document library using a particular custom content type. This meant I was going to need to write a little code. I decided to keep...(read more)

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)

SharePoint as an Application Platform

C-Dog's .NET Tip of the Day — Wed, 31 Oct 2007 20:01:42 GMT

I normally focus on actual useful information rather than just opinion, but today I am going to deviate a bit. After attening Tech Fest and listening to the elitists bash SharePoint as usual, I thought it was time for a post. I'll be the first to...(read more)