'Tis a SharePoint bug, it is!

I ran into this a few weeks ago, but had to delay dealing with it, for the sake of [somegoodreason]. Now I'm back on track, and I'm obviously going to whine about it to you.

The background for this problem is simple:

I create a site collection from a site definition, using code. This sitedef contains a couple of aspx files, which are put on the base of the new site's root web. To put the files there, I have Module tags in a feature's elements xml. The module tag contains a Name attribute, which is required, and used by SharePoint to look up the library it is to put the files in.

The thing is, though - ghostable files on the root of a web don't go in a library. So as SharePoint prepares the site, it fails to locate a non-existing library (which it wouldn't use anyway), and takes note of the error, but then carries on, as the library *really* wasn't required (told you).

Here's me explaining that by use of poor penmanship and malplaced creativity:

Click it to view larger version.

So while that scenario works out ok, what I'm actually doing, is calling the create-sitecollection code via a WCF service. And that plays out as follows (gore included):

Click it to view larger version.

The problem is rooted in SharePoint's logging code, which includes a routine to step back through the call stack, taking note of the where the failed call originated from. In this case, that would pass through the calls made by SharePoint to look up the library, deploy the file, open the elements, [...] and eventually into the service - which is internally in WCF an invoked DynamicMethod.

SharePoint's logger essentially does this:

StackFrame frame = trace.GetFrame(i);
builder.Append(frame.GetMethod().DeclaringType.ToString());

And that doesn't sit well with the DynamicMethod, which isn't really your run of the mill method (it's a dynamically compiled at runtime), and sure as batman doesn't have a DeclaringType. Calling the ToString() on a null reference ... not good at all.

Thus, SharePoint logs itself to bits and pieces, and I'm left none the wiser at the other end of the line.

So the moral of the story is:

1. Null references are bad
   
2. Assuming that all methods are declared somewhere, in a language which supports emitting and compiling code at runtime - also bad
   
3. Logging events that aren't actually errors, and which no part of the application cares about either way, even when logging is turned off - well you'll figure that one out yourself.
   

Update: I made a new post (and obviously an illustration) on a workaround: here