Getting the ContentType from an ItemAdding Event Handler

Inside an event handler for an ItemAdded event, getting the List Item’s ContentType is as easy as

var contentType = properties.ListItem.ContentType;

However, for ItemAdding, properties.ListItem is null.

Luckily, the ContentType name and Id are part of the properties.AfterProperties collection – the following will work:

SPList list = properties.List; 
string contentTypeName = properties.AfterProperties["ContentType"].ToString(); 
SPContentType contentType = list.ContentTypes[contentTypeName]; 
SPFieldCollection fields = contentType.Fields;

Between the AfterProperties field values and the content type field collection, you typically have all that you need... Just remember to not depend on properties.ListItem.

SharePoint 2010: Managed Metadata fields and the TaxonomyHiddenList

Notes to self and others:

When you create a Managed Metadata (aka Taxonomy) field in a SharePoint 2010 list or library, the field’s schema will look something like this:

<field id="{f6d2b908-4ed4-42f8-a491-e1177ed57596}" version="1" 
  rowordinal="0" colname="int3" name="Tags" staticname="Tags" 
  sourceid="{58701f50-42a0-4c3d-8fdd-fb6f3a798bc4}" 
  enforceuniquevalues="FALSE" required="FALSE" 
  showfield="Term1033" 
  webid="956683ae-54b0-46c4-8fe6-8e14309b6fcd" 
  list="{4c231f71-5ed3-49aa-a62f-3fbb9a900bd0}" 
  displayname="Tags" type="TaxonomyFieldType">

  <default>1;#A|6832dce7-bd84-4afc-8311-d5a1367dc282</default>
  <customization>
    <arrayofproperty>
      <property>
        <name>SspId</name>
        <value xmlns:p4="x-instance" p4:type="q1:string" 
xmlns:q1="x">5dc61acc-dfa4-41dd-aa85-dd71d054ab1f</value>
      </property>
      <property>
        <name>GroupId</name>
      </property>
...

(field definition and namespaces shortened for readability)

Some of the notable attributes are:

• Type – obvious
• WebId - The current list’s web
• SourceID - The current list’s id
• List - The ID of a “TaxonomyHiddenList” which resides in the current web, but as the name implies, is hidden.
• ShowField - the field in the TaxonomyHiddenList to display – looks like it’s locale enabled.
• The SspId property is also crucial – it is the TermStore ID used to access the TermSet – more on that in another blog post…

The TaxonomyHiddenList’s schema looks like most lists’ schema – HUGE.  Some of the interesting fields are:

• IdForTerm - in the case of the default value above (A) this field’s value matches the GUID 6832dce7-bd84-4afc-8311-d5a1367dc282
• IdForTermSet - this appears to be the term set id from the MM data store – I have another column in my list which is not tied to a centrally managed metadata store – its value shows as 0000….-00… etc.
• IdForTermStore – in my instance, this GUID is the same for both the managed and non-managed metadata field – matches the SspId above.

How to Upgrade a WSPBuilder Project to SharePoint 2010

<UPDATE date=”2009.12.02”>: WSPBuilder Extensions 2010 Beta 1.3 (or newer) makes the below mostly obsolete – though I was still not able to deploy using the VS add-in – I got a message stating my SPTimer Service was not running.</update>

Based on advice from Bjørn Furuknap (@furuknap, http://furuknap.blogspot.com/2009/11/using-wspbuilder-for-sharepoint-2010.html) I was able to deploy to SP 2010 a rather complex WSPBuilder-based SharePoint solution that I first recompiled in VS 2010.

Steps were:

1. Download the command line version, with the x64 cablib dll
2. Upgrade your VS 2008/2005 solution to VS 2010
3. Replace your 12 references with their 14 equivalents - most will be found in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI
4. Compile your VS solution - this SHOULD work
5. Use the wspbuilder command line tool to create, but not deploy your wsp (use wspbuilder -help for instructions)
6. Use stsadm -o addsolution -filename <yourwsp> to deploy the solution

SharePoint Office Server 2010, on Windows 7, in Google Chrome

It took a few hours of downloading, a few hours of installing (with workarounds), but I now have SharePoint 2010 Office Server Beta (aka the MOSS upgrade) running on my Windows 7 laptop; and as can be seen, it renders beautifully in Google Chrome. <UPDATE1> installed and uninstalled the dang thing several times, with the same result:  I keep getting WCF errors:

System.Configuration.ConfigurationErrorsException: Unrecognized attribute 'allowInsecureTransport'. Note that attribute names are case-sensitive. (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebClients\Profile\client.config line 56)

</UPDATE1>

<UPDATE2>
I completely uninstalled every bit of SharePoint 2010, Visual Studio 2010, .net 4, and every prerequisite of SP.  Then reinstalled.  This time I ran the configuration wizard (as admin) while connected to the domain controller (via vpn).  MOST of SP2010 now seems to work.

I then tried adding the local SP admin account (hat I had created for my first install) to the Farm Administrators group.  Same damn WCF error.

So I simply backed up then edited client.config to remove the offensive attribute both from line 57 and from a second instance on line 97.  Then I rebooted and tried the Farm Admin Addition again.

Same error message (note that I am NOT running SPF, I am running the full Office Server version)…

… but different cause this time:

Local administrator privilege is required to update the Farm Administrators' group.

Could this be a limitation of running SharePoint2010 on Windows 7?
</UPDATE2>

The one Another challenge of the installation was that the Configuration wizard would fail repeatedly on step 2 (of 10) when attempting to set up the configuration database.  The error was “user can not be found”.  I then noticed that my domain account did not have full admin rights on my SQL server instance, unless I started SQL Management Studio as Run as Admin.

The workaround I used was to create a local admin account, grant that account full db access, switch to the new admin account, run the configuration wizard, and then switch back to my regular user account.  Crude, but effective.

<UPDATE2>
The better alternative is to connect to your corporate network to gain access to your domain controller.  On my 3rd, 4th and 5th (!) time running the configuration wizard, this was the approach I took, and it seems to work well.  (I understand this is also something that is necessary for the VS 2010 TFS install.)</UPDATE2>

I have no opinions on speed, etc – more of that to come, I’m sure.

<UPDATE3>
So I finally ended up scrapping Windows 7 AND 2008 R2.  With our code, there just was no getting around compatibility issues.  So for now I am running on good ol’ Windows Server 2008 x64.

Can’t wait for MS to release bootable, sysprepped developer vhds for this...
</UPDATE3>