Ok, you’re back and have read all those? Great! I’ve got a few more for you.

1. Shared Fields are push down only:

   If you go into a document within a document and edit a property which is set as a shared property for the Document Set that change does not get propagated to the either the containing Document Set or to other documents within the set. If you need to change these across the entire Document Set you must make the change to the Document Set itself and then SharePoint will propagate these changes down.

2. Versions have to be declared:

   Despite the fact that a Document Set itself can have metadata which users change there is no automatic tracking of changes made. You must use the Capture Version functionality manually to record changes made against the metadata at a Document Set level.

3. No Check-In/Check-Out functionality:

   The notion of check-in/check-out does not apply to Document Sets. This kind of makes sense when you consider that they are just special folders and a check-out at the folder level would imply that they user had also checked out all child documents. But it’s a little annoying, especially as there is metadata against the Document Set which users can freely edit with no automatic version history captured.

Note the missing padlock icons on some files. The files missing the padlock were retrieved on my last Get Latest operation.

To ensure that Visual Studio treats these correctly and enforces source control behaviour you have to refresh the source control connection. Ensure that you select the solution file, to refresh all projects, or just a single project to target the refresh at just that project. Then select File > Source Control > Refresh Status or Alt + F, Alt + R, Alt + T for you keyboard jockeys out there.

Lo and behold, padlocks are present and source control behaviour is correct!

I’d been using this code to create my document sets:

/*
Broken but sort of works
*/
public static void GenerateNewApplicationDocumentSet(string applicationNumber, SPList targetLibrary, SPWeb web)
{
	if (applicationNumber == null) throw new ArgumentNullException("applicationNumber");
	if (targetLibrary == null) throw new ArgumentNullException("targetLibrary");
	if (web == null) throw new ArgumentNullException("web");
	//You can use a hashtable to populate properties of the document set
	var docsetProperties = new Hashtable {{"Name", applicationNumber}};
	var documentSetContentType = web.ContentTypes[ContentTypeNames.ApplicationDocumentSet];
	documentSet = DocumentSet.Create(targetLibrary.RootFolder,
                                                    	applicationNumber,
                                                    	documentSetContentType.Id,
                                                    	docsetProperties,
                                                    	true);
}

Creating my Document Sets via the UI worked fine and gave me the right icon and a link to my Welcome Page. I was well puzzled. After a bit of head scratching and getting back to SharePoint basics I realised my mistake. I was creating an instance of the Documents Set Content Type that was on the SPWeb and not that which was bound to the Document Library.

Once I start using the content type from the library things started working perfectly!

public static void GenerateNewApplicationDocumentSet(string applicationNumber, SPList targetLibrary)
{
	if (applicationNumber == null) throw new ArgumentNullException("applicationNumber");
	if (targetLibrary == null) throw new ArgumentNullException("targetLibrary");
	//You can use a hashtable to populate properties of the document set
	var docsetProperties = new Hashtable {{"Name", applicationNumber}};
	var documentSetContentType = targetLibrary.ContentTypes[ContentTypeNames.ApplicationDocumentSet];
	documentSet = DocumentSet.Create(targetLibrary.RootFolder,
                                                    	applicationNumber,
                                                    	documentSetContentType.Id,
                                                    	docsetProperties,
                                                    	true);
}

Subtle but telling reminder that the content types bound to lists are different from those site wide content types that they inherit from.

Now usually this means that you’re trying to use a managed property without mapping it to a crawled property or before doing a full crawl after creating the managed property. Neither of these were the case for me.

In my case I was trying to search on a DateTime field, which I’d set up as a Managed Property called DocDate, and I’d decided to base the format of the search term off what SharePoint creates from the advanced search screen which is “Write>=02/03/2012”.

When I was looking for a known document in my corpus which should have a DocDate of 15/02/2012 using the search term “DocDate=15/02/25012” I was presented a familiar message, however I knew I’d wired up the Managed Property correctly.

So I downloaded the SharePoint Search Service Tool and tested another search to verify that my DocDate property was populated and getting returned, sure enough, it’s coming back in search results.

After a bit of head scratching and cursing I hit upon the problem.

1033.

I was getting bitten by the fact that the only “English” installation of SharePoint anybody can use is actually American, and their horribly broken date format is used by the query engine despite the fact that the Search Centre site has the locale set to en-NZ. A quick change of query to use ISO date formatting and BOOM! I’ve got results!

In short, SharePoint will give you the “Property doesn’t exist or is used in a manner inconsistent with schema settings” error message when it couldn’t parse a Date.

What the hell? I’ve entered dates prior to 1970 via the UI before. A quick search showed me this great post: Proper way to set DateTime format of a Sharepoint list item datetime property. Perfect.

I have one small addition to make to that. You can use the DateTime format string of “s” for ‘sortable’ date times.

fileToUpload.Properties["DateField"] = date.ToString("s");

Sorry.

In all honestly when I got back from the US after that trip I was a bit burnt out. Pulling large hours for an extended period of time just caught up with me. I really love the work I got to do over that time, building a keynote demo for the SharePoint Conference was an amazing experience! But it’s nice to slow down a little and enjoy life too.

So I took a bit of a break from the long hours to spend more time with my wonderful fiancée and spent some time getting out hiking the Waiatakere ranges. Well I’m glad to say that I’m starting to blog again, this is the first of three posts that will go out today.

I’m going to TRY to keep up  a cadence of a post per week, but I do throw out the caveat that I am getting married in September so I’ll likely go dark for a few weeks around that.

I’m really excited about lots of cool things things that are happening this year, the first, and second, of these being the Australian and New Zealand SharePoint Conferences where I’ll be presenting on using LiveID and Claims based authentication. Even if my topic isn’t your bag they’ll be a great pair of events industry leading experts, MVPs and two MCMs presenting. So I strongly urge you to hit up your boss and get yourself to Melbourne for March 20&21 or Auckland for March 28&29.

Anyway, it’s good to be back.

I had a real blast co-presesnting that session with Chris. As promised I have a bunch of resources for you to download and peruse.

Disabling Mobile Re-direction via PowerShell

Hmmm, apparently WordPress won’t let me host any useful file formats in my site (not even plain .txt files!!!) so sorry…. My plans of giving you folks full Visual Studio solutions as zip files has been foiled! I’ll work out a cunning plan to get around this later.

In the meantime:

The custom re-director I showed off was based off this MSDN article: http://msdn.microsoft.com/en-us/library/ms441925.aspx. Essentially you should:

• Create a mapped folder in you SharePoint Solution, mapping it to 14HIVE\TEMPLATE\LAYOUTS\MOBILE
• Into this add your own custom aspx page that inherits from Microsoft.SharePoint.MobileRedirection.SPMobilePage
• Override the OnInit method to provide your custom redirection
• Create a copy of the existing mbllists.aspx as mbllists.old.aspx, or similar
• Replace the existing mbllists.aspx with your own custom page that contains:

<SPMobile:SPMobileForm RunAt="Server" PageType="HomePage" Paginate="true">
	<SPMobile:SPMobileHomePageRedirection ID="SPMobileHomePageRedirection1" RunAt="Server" 
    PageFileName="CustomMobileRedirect.aspx" />
</SPMobile:SPMobileForm>

• Deploy the solution

The HttpHandler that I used to trick SharePoint into not re-directing I sourced from the blog of Waldek Mastykarz: http://blog.mastykarz.nl/inconvenient-sharepoint-2010-mobile-redirect/.

I then coupled it with a really simple webpart that contained the following code.

using System;
using System.ComponentModel;
using System.Web.UI.WebControls.WebParts;

namespace VariationsRedirector.RedirectWebPart
{
    [ToolboxItemAttribute(false)]
    public class RedirectWebPart : WebPart
    {
        protected override void OnInit(EventArgs e)
        {
            if (Page.Request.Browser.IsMobileDevice)
            {
                string mobileUrl = GetMobileSiteUrl();
                Page.Response.Redirect(mobileUrl);
            }
            base.OnInit(e);
        }

        /// <summary>
        /// Gets the Mobile URL form the config settings list if it exists
        /// </summary>
        /// <returns>The mobile URL</returns>
        private string GetMobileSiteUrl()
        {
            //This is just hard coded to change the URL of the current request,
            //swaping the mobile variation label for the www variation label, 
            //hey, it's demo code...
            string mobileUrl = Page.Request.Url.ToString().ToLower().Replace("/www/", "/mobile/");
            return mobileUrl;
        }
    }
}

Many thanks to the Conference team for allowing me to present and to all of you that came along to my session
Feel free to reach out to either Chris of myself if you have any further queries

To resolve this you’ll need to call the GetViewCollection method for a given list and then parse the result to find your Guid. I’m a total newbie to jQuery and client side scripting so I found this a little tricky to get right, but I got there. So, here’s a helper for you use:

function ResolveListGuidFromName(webUrl, listName, viewName){
	var guid;
	var filter = "View[DisplayName='"+ viewName +"']";
	$().SPServices({
	    operation: "GetViewCollection",
	    async: false,
	    webURL: webUrl,
	    listName: "Votes",
	    completefunc:function (xData, Status) {
			guid = $(xData.responseXML).find(filter).attr("Name");
		}
	});
	return guid;
}

Not too bad for my first hack at this stuff.

Thankfully there is a handy command line tool that you can use called TFSSecurity.exe, by default you can find it in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE

What you need to run is:

TFSSecurity.exe /collection:http://<serverUri>:<port>/<virtualDirectory>/<collectionName>/g+ “[<projectName>]\<group>” n:”<DOMAIN>\<user>”

Replace everything in angle brackets with the values that match your environment. As a rule of thumb for default install the virtual directory is tfs, the port is 8080 and the collection is default. So to add INTERGEN\Gavinb to project Awesome as a contributor the command looks like this:

TFSSecurity.exe /collection:http://tfsserver:8080/tfs/default /g+ “[Awesome]\Contributors” n:”INTERGEN\gavinb”