The following gotcha was a pretty nasty one for me (I'd say about 2 hours of lost time worth). Supposing you have some content types deployed at the site collection level and you want to add them to a document library of a sub-site (web) plus configure them a little bit, like so: foreach (string contentTypeName in ToAttachToListContentTypeNa... { // Get site collection content type SPContentType siteContentType = web.AvailableContentTypes[c... // Add to library and configure SPContentType...

To paraphrase a heavyweight blogger, this is the first post in (probably) a infinite number of posts about Sharepoint Gotchas. Today's gotcha: why doesn't my custom content type have any columns? It took me quite some time (including a little foaming-at-the-mouth time) to figure this out. Suppose you declare a custom content type in CAML that you'd like to just inherit all its columns from its base content type, without defining any of its own, like so: <ContentType ID="0x010100D4C041607B6A400...

Although this might be present in other versions of DNN too, I've found that if I add the attribute "theme=something" to the <pages> element in web.config, I get a compilation error in FCKImageGallery.aspx: "Error 129 Error parsing attribute 'theme': The 'theme' property is read-only and cannot be set. " That is because the page's codebehind class derives from the FCKGallery class, which already has a Theme property. This is unfortunate, because, although DNN has its own skinning mechanisms,...

Due to much frustration and lost time, I'll try to summarize in this post the "naming" conventions to be used when defining and/or referencing IDs (some of which are, in fact, GUIDs, and others contain GUIDs) in Sharepoint 2007. If you're thinking "what the heck?! aren't GUIDs always the same format?!" you're half-right: they should be, but not in sharepoint. So if you're a newbie to sharepoint 2007 (or wss 3.0) like me, the following tips regarding how element id's should be written might save you...