Bernado Nguyen-Hoan's Blog – Coding Stories from an IT Mercenary

What you can/cannot access in BeforeProperties and AfterProperties in list event receivers can be mysterious.

Here is a very good/clear description of what you can expect when and where: http://www.synergyonline.com/blog/blog-moss/Lists/Posts/Post.aspx?ID=25

In addition to what’s in the above link, I found that for ItemUpdating and ItemUpdated, AfterProperties will contain:

• Only fields that have changed IF the list item was being updated through code (e.g. your custom app)
• All fields in the edit form, even if they have not been changed, IF the list item was being edit through the OOTB GUI.

The 2 behaviours above may be consistent with each other. An explanation could be that the OOTB GUI simply inserts all incoming values from the form into the item regardless of whether they were updated by the user.

I wrote my first console app against SP2010 in VS2010 the other day and ran into the above exception at the very first line:

using (SPSite site = new SPSite(http://localhost)

It turns out because my console app was targeting x86 and SP2010 is of course x64. Changing the console app to x64 (or Any CPU) in Project Properties \ Build solved the problem.

Well actually this is really easy to do now in SharePoint 2010.

In Central Admin, go to Monitoring > Review job definitions > [job] and you get the setting screen below.

Notice that there is also a RUN NOW button – which will come in very handy for developers.

Neither of these were not possible through the UI in SP 2007.

If you forgot to include a default constructor in your timer job class, you will get the error below when activating the feature that installs the job:

SharePointProject1.TimerJobs.TrackingTimerJob cannot be deserialized because it does not have a public default constructor.

The problem is, if you were doing (and deploying) this through Visual Studio 2010, it will install and attempt to deploy the solution. During solution deployment however, feature activation will fail, but the solution will be marked as deployed anyway in SharePoint.

The problem is now you can’t retract/delete this solution from SP, because you will run into the error above.

To fix this, fix your timer class (i.e. include the default constructor), then un-GAC the assembly containing your timer job, then try retracting/deleting the solution and it will work.

Today I ran into an issue where I intermitently get the following error when attempting to loop through a SPListItemCollection in a foreach loop:

Object reference not set to an instance of an object. at Microsoft.SharePoint.Library.SPRequest.SetVar(String bstrUrl, String bstrName, String bstrValue)
at Microsoft.SharePoint.SPListItemCollection.EnsureListItemsData()
at Microsoft.SharePoint.SPListItemCollection.Undirty()
at Microsoft.SharePoint.SPBaseCollection.System.Collections.IEnumerable.GetEnumerator()
at System.Linq.Enumerable.d__aa`1.MoveNext()
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at CAPS.Bll.Repositories.SharePointListRepositoryBase.GetItemsByQuery(SPQuery query)
….

I was looping through a collection that was returned using a CAML search. The error would occur after the 2nd or 3rd time running the same code.

It turned out that it was because my SPWeb object was being held in a static variable (it was an app page, not a console app), and the SPList was being accessed from this SPWeb. Changing the SPWeb to instance variable resolved the problem.

I think it’s probably safer to stay away from static variables in SharePoint dev, particularly if the code is going to run in a web context.

So today I needed to investigate certain settings of a site collection in our dev environment. I went to the web site but cannot see Site Settings in the Site Actions menu at all. I checked Central Admin and I am a Farm Administrator, as well as Site Collection Administrator for that site collection. When I used SharePoint Mananger (SPM) to update a property of a list I get an Unauthorised Exception. I knew this was not normal because I know I should be able to update this property through SPM.

It turns out the site collection was locked.

Use this command to check if the site is lock:

stsadm -o getsitelock -url http://server/siteCollection

If the site is lock, use this command to unlock it:

stsadm -o setsitelock -url http://server/siteCollection -lock none

Site Settings came back, and everything else was the way they should be after I unlocked the site collection.