Then I tried to create a Custom List. I had event receivers attached to custom lists (ListTemplateID=100 for those who care) and i got this:

Cannot insert the value NULL into column ‘Name’, table ‘[somesharepointcontentdatabase].dbo.EventReceivers’;
column does not allow nulls. INSERT fails.
The statement has been terminated.

Took me a good two hours of trying everything I could think of with my XML and code, only to be repeatedly thwarted by this database-level error! I tried commenting out different sections of my receivers and still got the error. When I commented the entire <Receivers> section, things ran fine, but not the <Receiver> items inside. What the hell is going on? Read on!

I’ll give an example of what I’m talking about here – the following comes from MSDN:

feature.xml:
<Feature
Scope=”Web”
Title=”Simple Updating Item Event Handler Registration”
Id=”A6B8687A-3200-4b01-AD76-09E8D163FB9A”
xmlns=”http://schemas.microsoft.com/sharepoint/”>
<ElementManifests>
<ElementManifest Location=”elements.xml”/>
</ElementManifests>
</Feature>

inside the feature.xml file (above) it references the following file:

elements.xml:

<Elements xmlns=”http://schemas.microsoft.com/sharepoint/”>
<Receivers
ListTemplateOwner=”ADDABAAA-1111-2222-3333-111111111111″
ListTemplateId=”104″>
<Receiver>
<Name>SimpleUpdateEvent</Name>
<Type>ItemUpdating</Type>
<SequenceNumber>10000</SequenceNumber>
<Assembly>SimpleUpdateEventHandler, Version=1.0.0.0, Culture=neutral, PublicKeyToken=10b23036c9b36d6d</Assembly>
<Class>MS.Samples.SimpleItemUpdateHandler</Class>
<Data></Data>
<Filter></Filter>
</Receiver>
</Receivers>
</Elements>

This works fine. Here’s something interesting though: any comments – <!– Like this –> - you have in the <Receivers> node will be literally interpreted as <Receiver> nodes! That means whenever it tries to attach event receivers to any list, it treats the comments as actual receivers! That’s right, for whatever reason, the code that ties event receivers to lists literally loops through every node (comments are still considered nodes!) and tries to use them instead of using any sort of XPath. How hard is it to use “//Elements/Receivers/Receiver” as your node collection XPath? I really hope whoever wrote that code got the ruler or something.

The solution: Remove comments from your Feature xml file(s).

I say this because God only knows where else this is happening, and the odds of you realizing that it is something that should just work, like comments, are probably not that high. Remember folks, sometimes the most obtuse problems have the most simple answers. Try not to over-think things.

A huge thank you must go out to Janne Mattila for being the first (and apparently only according to Google) documenting this. I wish I had looked sooner.

I’m bringing this up from an exceptionally small thing I noticed while at work today. As I have previously stated, I work with SharePoint. Much of the time I am branding it (though not in my current project!) and so I have a rather intimate and abusive relationship with the program. I find myself constantly finding weird styling quirks put into the environment that prove that SharePoint was built by a large group of people.

There are many instances within SharePoint – and I’m sure within WSS as well – where certain styles that should be consistent end up being done completely different ways. I wish I had a screen shot as an example, but you’ll have to use your imagination here. Picture two dropdown buttons. When you hover over them, they glow, and a menu appears. No picture the HTML for both dropdown buttons being completely different, with no shared styles or markup whatsoever.

This happens all over the place. Hell, there is markup all over the place that is either broken, non-standard (don’t get me started on WSS/SharePoint and it’s default markup) and over 6 thousand lines of styles if you add up all the sheets. 6 thousand! There is no need for that, and yet it exists because of – say it with me now – the lack of consistency.This lack of consistency then cascades down to people like me, who are stuck styling the damned things. Had there been a discussion between the differing groups, or the markup left to a third group so that they could all be structured the same way other peoples lives would then be made easier.

Another example I can bring up is with code. My code, my co-workers code, random interweb code, it happens everywhere. It is far more frequent when you work on rapid products, or many projects that build off of their predecessor. I can speak from experience that unless you code with the future in mind you will end up patching things… usually more than once.

In a perfect world you’d be able to properly scope your work out, develop your use cases, figure out your flow, and develop in a modular, expandable way. This of course requires a couple things: Time, patience, and knowledge. I can assure you that even if you think you have all three you don’t. The only time this can ever happen is when you are developing something for yourself and even then more often than not you’re just throwing something together for your own use, and those tend to be the worst for patch jobs… at least from my experience.

In the end all I can say is plan things out. Figure out a system and stick to it; even if it’s not the best it will at least not be the best everywhere. This makes it much easier to upgrade/fix later on. If you come up with 5 different solutions for 5 different things when they could all share common attributes, you are just making more work for yourself.

Save your time, your brain, and your fellow workers from the agony of added work brought about by inconsistency. Get a game plan, stick with it, and for the love of god: be consistent.

P.S. I managed to spell consistency wrong every time in this post while writing it.

P.P.S. Except for the one in the first postscript.

Update:

Success! I have a screen shot of the dropdown menus in question!
(Technically this update happened before the post went public, but whatever)