If you’re using the handy Document Sets feature in SharePoint 2010 you may run in to a small issue where you make some changes to your document set (e.g., add/remove content types from the allowed contents). When you do this, and push changes down to existing document sets, you’ll see a little yellow bar appear on each document set with the message

“Content Types that are available to this Document Set have been added or removed. Click here to update the Document Set.”

The reason is that the document set refresh date needs updating. Quite why SharePoint can’t manage this for you, is beyond me, but nevertheless, if you do click the yellow bar, it disappears. But it still remains for all your other document sets. Irritating. So here’s how to remove the little yellow bar with the message using Powershell. The neatest way is just to provision the document set.

The Exchange Web Services Managed API is a great tool for exposing Exchange Web Services to a .NET programming environment. You are able to work with all the key features of an Exchange Mailbox, such as downloading messages. In my particular case, I’ve been capturing emails and storing them in a SharePoint document library. The upload to SharePoint can be achieved by passing in a MemoryStream object - that is, you read an EmailMessage to memory, and then upload it to SharePoint.

I’ve been working with Kofax Express 2.0 recently to move documents from a scanner directly in to a SharePoint document library. I was using a custom list definition (created in Visual Studio) but was experiencing a strange error. If I created an instance of my list through the UI and then tried to scan from Kofax directly in to SharePoint, it was working no problem. However, if I tried to scan directly to SharePoint to the instance of the list created by the Visual Studio solution, I was getting the common error - “Object reference not set to an instance of an object”.

If you’ve encountered anything like this problem, then you may have had to update the permissions that a specific SQL login has. However, if the user you’re trying to edit is mapped to dbo, then you’re not allowed to make changes. There are ways to do it, but you need a pretty thorough understanding of what you’re trying to achieve. There’s a quick way around this using only the GUI. In SSMS, open the properties of the database(s) you need access to.

Painted lady butterfly timelapse showing a butterfly turning out of its chrysalis. First experimentation with timelapse stuff. This was a crummy old webcam attached to my computer. Apparently YouTube took offence at my choice of copyrighted music. Bastards.

You may encounter a random error when using a custom Visual Studio SharePoint 2010 workflow. Everything appears OK, but when you go to edit the item that the workflow is running on, the EditForm fails to load and you see an error like:

`Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.ArgumentNullException: Value cannot be null.
Parameter name: s

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[ArgumentNullException: Value cannot be null.
Parameter name: s]
System.IO.StringReader..ctor(String s) +10151478
System.Xml.XmlDocument.LoadXml(String xml) +51
Microsoft.SharePoint.Publishing.Internal.WorkflowUtilities.FlattenXmlToHashtable(String strXml) +90
...
`

Yet another SharePoint vagary. If you’re trying to deploy a feature and get the unhelpful error: “Error occurred in deployment step ‘Activate Features’: Object not set to an instance of an object” check the scope of the feature that you’re trying to deploy. I added a new feature to a project that had another working feature. Both were calling the Microsoft.Office.Workflow.Feature assembly but only one was failing and it was only after a lot of messing about that it turned out to be this innocuous little setting.

Quick tip: this plagued me for a while. You may develop a custom workflow which should only be associated with particular content types. You can deploy it to your site and then manually associate it to your content type. It’s possible to do this in code but the process isn’t as straight forward as it should be. Not to mention the fact that it’s infuriatingly hard to debug EventReceivers (“no symbols have been loaded” misery!).

A frequently asked question in the MSDN forums is “how you can get access to the user who is interacting with your workflow?”. For example, the user modifying a task. The workflow is likely running in a different context and/or session to your browser session so there’s not an obvious tie-up.

However, in this scenario, you can get the login name of the person who modified the SharePoint task, via the Executor property of the OnTaskChanged event. Simply bind the Executor property to a string (e.g., “taskLastModifiedBy”) and whenever the task changes, SharePoint will copy the user ID to this property in the format of DOMAIN\LoginName. You can then get an SPUser object for that login name with, e.g.

SPUser user = workflowProperties.Web.AllUsers[taskLastModifiedBy];

Note: On a related subject, and the thing that prompted this post - if you’re trying to update a Person or Group field on your workflowProperties.Item, then you must pass it an SPUser object! This is bizarre, because other types of list (e.g, the task list) you can pass it a string and SharePoint will do the rest. I spent ages and all kinds of different things and always getting the “Invalid data has been used to update the list item. The field you are trying to update may be read only.” error. Annoying.

One method for persisting data in a SharePoint environment is the use of Infopath forms. Infopath stores data in your form in XML format. I have a form which has a “comments” box where people add new comments as they progressively update the form and a “consolidate comments” box which shows all previous comments*. However, Infopath forms don’t natively support appending new data to existing data - and new comments added may blow away any previous comments.