If you use the CssRegistration and CssLink controls on a SharePoint page, core.css is always added to the HTML page last.  This means that any styles in core.css will override the styles you’ve defined in your custom stylesheets.  Does this make sense?! No.  But, like many other things in SharePoint, that’s the way it is.

A quick way to fix this is to just use a plain <link …> tag to include your stylesheets.  Since those aren’t processed server-side like links in the controls mentioned above, they will be loaded in the order you define in the HTML.

Heather Solomon has a blog post about this issue as well.

SharePoint has a nifty little feature which allows logged-in users to tell which other users are logged in (or away, or idle, etc.)  While this is a handy thing to have in an intranet setting, having your users prompted with the Name.dll download on a public web site isn’t desirable.  Here’s how to get rid of that pesky download prompt:

http://support.microsoft.com/kb/931509

Ever have SharePoint Designer tell you that something is checked out, but you know that it really isn’t? Here’s a link forwarded to me by a coworker:

 http://robgarrett.com/cs/blogs/software/archive/2007/12/14/sharepoint-designer-and-sharepoint-out-of-sync.aspx

Here’s a useful article with instructions on how to add new reports to the Site Actions / View Reports menu:

http://blogs.msdn.com/ecm/archive/2006/11/15/report-rapport.aspx

While working on a client’s MOSS 2007 public web site, I noticed that none of the reports in the Site Content and Structure page were not working. (There were duplicates as well, which I fixed by simply deleting the duplicate items from the Content and Structure Reports list at the root level.) I would click the item in the View drop down list, and the page would simply refresh. I checked the error log and found the following error:

SMObjectList.SmtReportsList: Reports List was not provisioned

Searching the web only revealed that other people were having the same problem. Microsoft wrote a KB article describing at least one symptom I was experiencing: duplicate report entries in the Site Actions menu. The article did not explain that the hot fix would also remedy the problem of no results showing up.

I emailed Microsoft customer support a few times, got the KB download, but didn’t feel very comfortable installing the hot fix on a production server just a few days before go-live. Also, the verbiage of the installation instructions seemed to imply that I had to export and re-import the site. Not something I wanted to do.

I then did some work to track down the error listed above by using .Net Reflector. The error was coming from a property called ‘SiteCollectionReportsListId‘ on the Microsoft.SharePoint.Publishing.Internal.WebControls.SMObjectList.SmtReportsList class. Of course, like all nifty properties in SharePoint, it was private. I was able to figure out where the property was getting its information, which was simply from the AllProperties hashtable in the SPWeb at the root of the site.

Writing a quick console app enabled me to find out that the problem site had this property set, but it was set to a GUID which didn’t point to a list on the current site. This GUID wasn’t changed when the site was imported using STSADM! I then wrote some more code in my handy little console app and tweaked the property to the valid GUID. Voila! Reports started working again!

Source Code  Executable