Errors that actually help to solve something

Well, suddenly it just happens – a YSOD. Just happened in my recent SharePoint dev-project.

Typical for SharePoint, this error is not obvious. Instead of the YSOD you’ll get a SharePoint specific page, telling you that something went wrong. No hint what happened or where the error actually occurred.

OK, so let’s head to the web.config and stop this hide-and-seek behaviors. I wanna know what’s happening. So we have to enable to show the actual CallStack and disable the use of CustomErrors.

<SafeMode MaxControls="200" CallStack="true" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">
<customeErrors mode="off">

OK, so now we’re talking. I have some sort of Null-Reference-Exception in my code. But this code just worked perfect on my dev-machine, so why is it failing on the test-machine? And why is something null anyway? The StackTrace tells me, that this happened in a property-getter.

private SPGridView _mySpGrid;
public void CreateChildControls()
{
    _mySpGrid = new SPGridView();
}
public bool HasRows
{
    get { return _mySpGrid.Rows.Count > 0; }
}

How can this be null? CreateChildControls is always being called, so the grid always exists. This cannot be the reason why.

OK, let’s try something totally irrational:

public bool HatWerte
{
    get { return _mySpGrid == null ? 0 : _mySpGrid.Rows.Count > 0; }
}

This could should actually not be necessary … except when this modification makes the Null-Reference-Exception to disappear. But just to make room for the next Exception. And now everything is making sense (and I could revert the above modification).

The next exception states:

Could not load file or assembly ‘System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ or one of its dependencies. The system cannot find the file specified.

D’oh!

My application was build against .Net 3.5 and I didn’t install that on my test-machine. Since the test-machine is a Windows 2003 Server running SharePoint 2007 there was no need to install .Net 3.5 – yet!

But .Net could have told me so from the beginning on – I would have understood this. But instead it was hiding behind some Null-Reference-Exception, just like a coward!

Permission by obfuscation

… or how to hide certain actions in SharePoint?

There are a couple of things, which can not be configured in SharePoint. For example you cannot configure, that users are not able to edit a list in datasheet view or in Excel or Access. Bummer!

But with a couple of lines of JavaScript this isn’t really a challenge.

<script language="javascript" type="text/javascript" src="/Scripts/jquery-1.4.2.min.js"></script>
<script language="javascript" type="text/javascript">
$(document).ready(function() {
  $("[id$='_EditInGridButton']").remove();
  $("[id$='_ExportToSpreadsheet']").remove();
  $("[id$='_ExportToDatabase']").remove();
});
</script>

Just place this code in a Content-Editor-WebPart on the page and off you go!

The ultimate list of GUIDs

I’m not really sure, what is disturbing me more – the fact that I am actually searching for a GUID on Google, or the fact that there exists a list of GUIDs.

OK, so I have sharepoint manifest file, which is part of a site-template. This template has a whole lot of features, which have been added by sharepoint to the manifest and actually not needed at all. But all those features are only being described by their GUIDs – so who is who?

Lucky for me Robert Bogue has a blog-post, where he features a list of MOSS 2007 GUIDs. This was perfect to identify the features und to remove all the unwanted features from the manifest.