This follows on from some of my other posts about deploying fields and content types programmatically. In this case, I was simply trying to add a choice field (SPFieldChoice) to a site, and then add it to some content types.

So I had something like:

var myCt = // snip - code to get my existing content type;

// create the choice column
                var fieldChoices = new StringCollection() { "choice1", "choice2", "choice3" };
                var docSourceField = web.Fields.Add("MyChoiceColumn", SPFieldType.Choice, false, false, fieldChoices);

                // get the column we just created 
                SPFieldChoice docSourceChoiceField = (SPFieldChoice)web.Fields[DocumentSourceColumnName];

                if (null == docSourceChoiceField)
                {
                    throw new Exception("Error: Couldn't get the docSourceChoiceField.");
                }
                                // add the new field to my content type
                myCt.Fields.Add(docSourceChoiceField);
                myCt.Update(true);

However, running this fell over with the error:

A while back I posted some info about using Event Receivers in SharePoint 2010 and a workaround to item values being null. Today, I needed to do something much more basic, and during an ItemUpdating event set the value of a column. I wrote the code that I knew would work - but, of course, it simply wouldn’t work. I did a spot of Googling about, and found the chaps at Tango Technology who had written a very simple solution to it. But - it wouldn’t work for me. I knew the event was firing - but no matter what I did, the new value just wouldn’t “take”.

I’m not a SharePoint administrator, but from time to time you have to get involved. I needed to migrate some data between farms but in order to do a backup / restore of e.g., Site Collections, version numbers have to be in range. Although the source server was reporting the version was OK, in Central Admin, it was saying that an upgrade was required. This is usually achieved by running the SharePoint 2010 Products Configuration Wizard.

If you encounter an issue, specifically in MySites, where you get an Access Denied error trying to edit the navigation, check whether you have the publishing feature enabled. I had this same issue when “Enterprise features” were re-enabled at the Central Admin, which for some reason enabled that on the My Site host, which isn’t needed.

A while ago, I posted about a problem deploying declarative XML content types and fields.

Error occurred in deployment step ‘Activate Features’: Key cannot be null. Parameter name: Key

I’ve just encountered the same error - but this time with a field being deployed programmatically - i.e., no XML at all. I was deploying a Managed Metadata field (TaxonomyField) and doing this:

TaxonomyField taxField = web.Fields.CreateNewField("TaxonomyFieldType", "My Field") as TaxonomyField;
taxField.SspId = termStore.Id;
...snip...
taxField.Update();
web.Fields.Add(taxField);

This seemed pretty reasonable - except for the error, of course. In this case it was caused by taxField.Update() - this is not required - the field doesn’t actually exist at this point.

You may encounter this issue when trying to deploy a Custom Expiration Formula for use as part of records management within SharePoint 2010. The error you may encounter is:

The SPPersistedObject, PolicyConfigService Name=PolicyConfigService, could not be updated because the current user is not a Farm Administrator.

This is a really nasty little error and it may be easy to miss as people have a tendency to use an empty try catch {} in their FeatureActivation so the feature activates but you’re not aware there is a problem. (Well, you become aware of it when for all the activation in the world, the “Use Custom Retention Formula” dropdown never changes from disabled.) It’s particularly annoying because you’re activating a feature at the Site Collection level - why would you need Farm Admin to do it? Well, it’s because it makes changes to the Content Service (or thereabouts) - and this is proven when you go to Central Admin > Security > Configure Information Policy Management > Retention and you’ll notice (after a successful activation) that your custom policy shows up in the “Resources” section.

I could play a game of “state the obvious” and say that SharePoint 2010 search is powerful. It’s really an incredible beast - and that’s even without any FAST goodies in there. But something that isn’t obviously supported OOTB but seems there’s a few people out there trying to do - search within folders, or in my case, Document Sets. SharePoint search was already configured and, actually, I could search within document sets, by doing a site wide search and then using the refinement panel (on the left hand side of a search result page in a search center) to narrow it down to my document set. What I wanted to do was perform this search directly from a search box.

As you use the refinement panel, you’ll notice that the URL changes, as you stack up the filters, and as it happens, that’s all that’s required is a properly crafted URL:

<br /> http://yoursite/_layouts/OssSearchResults.aspx?k=[searchterms] <strong>site:"http://yoursite/yourlibrary/yourdocset"</strong>

Note the highlighted part - you can restrict your search results to a specified document set (or folder) by supplying the URL in to the site: refinement option/filter.

With that bit taken care of, the challenge was to get a searchbox that would do this dynamically - i.e., craft the URL properly to apply the filter and direct through to the search results page properly. It’s possible using a standard search box and the trusty old Content Editor.

Event receivers enable you to run some action when a particular event occurs. For example, every time a new item is added to a list, you may want to run some code, or start a workflow. This is really handy - but be aware of some gotchas. SharePoint event receivers will generally be one of two types - an “-ing” event or an “-ed” event, such as ItemAdding or ItemAdded. As their name suggests, an -ing event runs whilst the the event is happening (and might therefore give you the option to cancel it) and -ed events occur after the event has occurred. You need to be aware of how these events run. Generally, the -ing events run synchronously, that is, they are blocking and run in the same thread/cycle that they were generated in, and -ed events run asynchronously, meaning the opposite - they are not blocking - they will be run in a separate thread and not block the execution of the main thread. You therefore need to be aware of what info may, or may not, be available to you when you run code in an event receiver.

This had me stumped for a while. I was developing a SharePoint-based client to consume a simple web service. I started by writing a console app version of the code before deploying to SharePoint. Fairly straight-forward - added a web reference to my VS2010 project, and used

MyWebService srv = new MyWebService();
srv.DoSomething();

Early on in the project, I didn’t give much to the fact that when calling the method on the web service, I was given a 407 Proxy Authentication Error. I just setup a simple proxy for it:

The Content Organizer (gah! Organiser!) in SharePoint 2010 is a nifty new feature that enables documents to be added to a single library (the “Drop Off Library”) and then let SharePoint route them through to the correct final resting position based on a set of configured rules. Rules can be configured per content type and allow conditions to be set based on metadata on the item. You can even use it to send documents - and document sets - between site collections, e.g., to a Records Center. Very cool.

Depending on your requirements, you may find you need to create a lot of rules which as with most things SharePoint can be cumbersome if you need to do it all through the UI. Fortunately, creating the rules programmatically is straight-forward.