It crashes on VSTO project templates, I was working on an Outlook add-in with WPF. strange. Has anyone else experienced this?

I usually use host headers when I create SharePoint web applications on my development VPC’s. I create a loopback entry in the hosts file to direct the FQDN to the current server.

Today I wanted to check out the IE Developer Tools that come in IE8, so I installed it on my VPC. I specifically unticked the option asking if Windows Updates should be installed – I did not want anything other than IE8.

So I fired it up, used it a bit on http://servername:80, then tried to log in SSP (http://mysites/servername:80). The credentials kept getting rejected. I checked things like site collection admins, app pool accounts, even recreated the SSP. Still no luck login in.

I noticed the following in the Event Log:

There was an Audit Failure immediately after an Audit Success entry. Here’s the failure error:

An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:        -
    Account Domain:        -
    Logon ID:        0x0

Logon Type:            3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:        administrator
    Account Domain:        mysites.mossdev2008

Failure Information:
    Failure Reason:        An Error occured during Logon.
    Status:            0xc000006d
    Sub Status:        0x0

Process Information:
    Caller Process ID:    0x0
    Caller Process Name:    -

Network Information:
    Workstation Name:    MOSSDEV2008
    Source Network Address:    127.0.0.1
    Source Port:        49329

Detailed Authentication Information:
    Logon Process:
    Authentication Package:    NTLM
    Transited Services:    -
    Package Name (NTLM only):    -
    Key Length:        0

I got a hint that the credentials are passing through the first time, but then the error appears. My guess was that IE8 did something, or it has some security feature I am not aware of. I launched Firefox and as I thought, logged into SSP successfully. Damn IE8, I haven’t even started using it yet.

 After some searching on the net I found the following resources describing the problem. I disabled the loopback check.

• IE8 Beta 2 – NTLM 401.1 (Not good for SharePoint developers)
• 401.1 Unauthorized error on SharePoint dev VPC after installing IE8 Beta 2
• and resolutions from my colleagues Brian Farnhill and Ishai Sagi: IE8 beta 2 authentication issues with host header configured sites
• http://support.microsoft.com/default.aspx/kb/896861

   1: <Field

   2:   ID="createguid"

   3:   Type="Lookup"

   4:   StaticName="Reference"

   5:   Name="Reference"

   6:   DisplayName="Reference"

   7:   AllowMultiVote="TRUE"

   8:   Required="TRUE"

   9:   FillInChoice="FALSE"

  10:   Group="Custom Fields"      

  11:   SourceID="{B45D7C95-C01B-4338-B0AF-88FFA4F3A5F1}">

  12: </Field>

Notice the missing List and ShowField and WebID attributes.

When creating a redeployable solution you don’t know the GUID of a site or web that gets created during deployment – it is different every time, but the lookup field needs to know the web that contains the target list.. Simply specifying the List attribute with a URL is not enough – it did not work for me even when I had the ShowField attribute.

The only way I could get the lookup field to work is to run code that updates the field properties after the field and web objects are created. Of particular interest are the LookupList, LookupField and LookupWebId properties of the SPFieldLookup class. I placed the code in a FeatureActivated method.

Here is the feature activated code that does this:

   1: private Guid _myFieldGuid = new Guid("createguid");

   2:  

   3: public override void FeatureActivated(SPFeatureReceiverProperties properties)

   4: {

   5:     try

   6:     {

   7:         // get web but DO NOT dispose as it belongs to SP

   8:         SPWeb web = properties.Feature.Parent as SPWeb;

   9:  

  10:         //get reference to the field and cast as SPFieldLookup

  11:         SPFieldLookup myField = web.Site.RootWeb.Fields[_myFieldGuid] as SPFieldLookup;

  12:         

  13:         //set properties

  14:         myField.AllowMultipleValues = true;

  15:         myField.PushChangesToLists = true;

  16:  

  17:         myField.LookupWebId = web.ID;

  18:         myField.LookupList = web.Lists["Reference"].ID.ToString();

  19:         myField.LookupField = "Title";

  20:  

  21:         //call Update to save changes

  22:         myField.Update();

  23:     }

  24:     catch (SPException ex)

  25:     {

  26:         //do something here

  27:     }

  28: }

Hope this helps.

Lets say you are inheriting from the OOTB “Event” content type. In it's schema it includes a “Recurrence” field (fRecurrence). This field has the following GUID: {F2E63656-135E-4f1c-8FC2-CCBE74071901} (notice the GUID is in retarded case.)

To create a child content type that inherits from “Event” but excludes the “Recurrence” field, you have to add the following in your custom content type definition (my example excludes some other fields):

   1: <ContentType Name="Custom Event" Group="Events" Description=""

   2:     ID="0x010200603E1A38891D40ba9CD81AB1A4A62049">

   3:     <FieldRefs>

   4:       <RemoveFieldRef ID="{f2e63656-135e-4f1c-8fc2-ccbe74071901}" Name="fRecurrence" />

   5:       <RemoveFieldRef ID="{7D95D1F4-F5FD-4A70-90CD-B35ABC9B5BC8}" Name="fAllDayEvent" />

   6:       <RemoveFieldRef ID="{9da97a8a-1da5-4a77-98d3-4bc10456e700}" Name="Comments" />

   7:     </FieldRefs>

   8: </ContentType>

The catch is that RemoveFieldRef ID's are _sometimes_ case sensitive. The ID must either be the same case as the GUID defined in the Field XML schema definition, or specifically LOWER case. This will not work:

   1: <ContentType Name="Custom Event" Group="Events" Description=""

   2:     ID="0x010200603E1A38891D40ba9CD81AB1A4A62049">

   3:   <FieldRefs>

   4:     <RemoveFieldRef ID="{f2E63656-135E-4f1c-8fc2-cCbe74071901}" Name="fRecurrence" />

   5:     <RemoveFieldRef ID="{7D95D1F4-F5FD-4A70-90CD-B35abc9B5BC8}" Name="fAllDayEvent" />

   6:     <RemoveFieldRef ID="{9dA97a8a-1DA5-4a77-98d3-4BC10456e700}" Name="Comments" />

   7:   </FieldRefs>

   8: </ContentType>

Crazy GUID fiasco!!!

• The “Recurrance” field does not get removed.
• The “All Day Event” field gets removed. You can use any case for this (WTF?!?)
• The “Comments” field (Description) also does not get removed. It is identified as {9da97a8a-1da5-4a77-98d3-4bc10456e700}, and you have to use lower case to remove it.

Inconsistent, or I am just missing the point. I've done some tests, but I still haven't found the reason as to why some fields need special cases for their GUID's. I am very keen to hear about other experiences on this. Very interested to know the actual reason for this, or whether it is a bug.

Conclusion:

If you are defining custom content types and you want to reorder or remove some fields from the parent (they always inherit), watch out for the case of the GUIDs. If you are getting duplicates, chances are your RemoveFieldRef ID's should be lower case (or the same case as in the field schema).

Hope this saves some hours.

Ever replied to someone’s email and commented between his/her lines, then changed the colour of your additions so they stand out? How boring… check this out:

If you are typing an HTML email, CTRL-ALT-M adds a comment just like in Microsoft Office Word:

 I wish I knew this a year ago! The thing is… I can’t find it in the ribbon bar. bugger.

 And today @merill showed me something else… automatically defining a prefix for your inline comments on reply:

To configure this, go to Outlook, click the Tools toolbar, select Options. Click the Email Options… button and find the “Mark my comments with:” settings:

 Awesome stuff, no more hard times in replying to bullet point emails.

Did the job!

“Computer Network Name” is a text field in my example. I want to only return results when that field has values.

• An existing content type spread across multiple lists
• A CQWP is required to query the items of that content type and group the results by the list which they belong to
• The group headings have to be links to the actual list
• There should be no visible change to the existing stuff
• There is an existing ItemAdded event handler attached to the content type

The challenge is, that by default the items returned from the CQWP don’t actually know much more about the parent list apart from the ListID that is returned as an attribute of the row element. You would think the list guid is all you need to identify the list instance, which it completely is, but since you are rendering XML with XSL Style Sheets, you don’t really have much flexibility in pulling actual information about that list.

I had a browse around the net to see how other people get the parent list name of row items – the most viable approach was the event handler. Since the already released version of the solution had an event receiver against the content type, my best option was to modify it to give me some information about the parent list.

• I added two hidden fields to the content type to satisfy the “no visible change” requirement – one for the list name and the other for the list URL (site collection relative).
• I modified the event handler to populate them

The next challenge was that the CQWP won’t see the hidden fields in the UI, so I had to set them manually.

The following properties inside the .webpart file of my CQWP allows me to add those fields to the grouping functionality of the web part:

   1: <property name="AdditionalGroupAndSortFields" type="string">ParentListName;ParentListUrl</property>

   2: <property name="CommonViewFields" type="string">ParentListName, Text;ParentListUrl, Text</property>

   3: <property name="GroupBy" type="string">ParentListName</property>

This MSDN article gives a good explanation on how to use these properties: http://msdn.microsoft.com/en-us/library/aa981241.aspx

The CommonViewFields property tells the query to return further fields into the row xml. You can reference the values of these inside the XSL. The AdditionalGroupAndSortFields will allow you to set it in the Group By section in the UI.

Here is the template inside my header XSL Style Sheet that renders the group heading as a link:

   1: <xsl:template name="CustomLinkedHeader" match="*" mode="header">

   2:   <div class="groupheader item medium">

   3:     <a>

   4:       <xsl:attribute name="href">

   5:         <xsl:value-of select="@ParentListUrl"/>

   6:       </xsl:attribute>

   7:     <xsl:call-template name="OuterTemplate.GetGroupName">

   8:       <xsl:with-param name="GroupName" select="@*[name()=$Group]"/>

   9:       <xsl:with-param name="GroupType" select="$GroupType"/>

  10:     </xsl:call-template>

  11:     </a>

  12:   </div>

  13: </xsl:template>

The rest of the XSL handles the parent list name automatically. The good thing is that the web part won’t display headings where items are not returned as they don’t exist in the result set. It also provides you the ability to filter on fields – great functionality.

That’s pretty much it. The CQWP is REALLY powerful, I love it and I now find XSLT stuff really fun too.

After playing around with XSLT for a while now, I have grown to love it and I think it is awesome and really flexible. When styling the CQWP, you sometimes have to get to the RAW xml data that comes out of it – it really helps you understand how XSL style sheets work when you have the raw view. In my case, I had to understand how the grouping functionality of the web part works, so I can incorporate it into my XSLT styling (more posts to follow).

The following XSL template dumps the xml for you:

   1: <xsl:template match="/">

   2:     <xmp><xsl:copy-of select="*"/></xmp>

   3: </xsl:template>

I place the above in my own “main” XSL file of the CQWP – I never edit the original one created by the Publishing Infrastructure feature called ContentQueryMain.xsl.

I replace the following template call with the 3 lines above:

   1: <xsl:template match="/">

   2:   <xsl:call-template name="OuterTemplate" />

   3: </xsl:template>

I also do a small change to the output tag (the first line after the opening <xsl:stylesheet tag)

   1: //the original:

   2: <xsl:output method="html" indent="no" />

   3:  

   4: //modified

   5: <xsl:output method="xml" indent="yes" />

This shows me the raw xml in a nice, structured way:

   1: /// <summary>

   2: /// Returns a generic collection of the ID and value of a Lookup-Field with multiple values.

   3: /// </summary>

   4: public static IDictionary<int, string> GetMultiValueLookupFieldItems(this SPListItem item, Guid fieldGuid)

   5: {

   6:     var returnValue = new Dictionary<int,string>();

   7:  

   8:     if (item == null)

   9:         return null;

  10:     

  11:     var lookupField = item.Fields[fieldGuid];

  12:  

  13:     if (lookupField.FieldValueType == typeof(SPFieldLookupValueCollection))

  14:     {

  15:         var lookupFieldValues = item[fieldGuid] as SPFieldLookupValueCollection;

  16:         if (lookupFieldValues == null)

  17:             return null;

  18:         foreach (var value in lookupFieldValues)

  19:         {

  20:             returnValue.Add(value.LookupId, value.LookupValue);

  21:         }

  22:     }

  23:     

  24:     return returnValue;

  25: }

To do this for a People or Group/UserMulti field – the SPFieldUserValueCollection type – just replace SPFieldLookupValueCollection to SPFieldUserValueCollection.

For something really cool, a generic method with casting at runtime would be really cool to accommodate both situations. I'd be interested on that.

Here is how to use the code:

   1: IDictionary<int, string> groups = theSPListItemObject.GetMultiValueLookupFieldItems(c_LookupFieldGuid);