Microsoft has a good checklist for code acceptance for developing Custom MOSS solutions.

Below are some points with useful links

• You avoid using AllowUnsafeUpdates. You use ValidateFormDigest() and, if necessary, use elevated privileges to interact with SharePoint objects. In cases where AllowUnsafeUpdates must be used, you ensure that AllowUnsafeUpdates is set to False in your try-catch-finally block, or you use a Dispose() method (as required by the IDisposable interface) to avoid security issues.What you need to know about AllowUnsafeUpdates (Part 1)
  What you need to know about AllowUnsafeUpdates (Part 2)
• When logging code, you use the Portal Log class to log the SharePoint Unified Logging Service (ULS) logs.Trace Log Example from Microsoft
• When using the Count property of a SPListItemCollection, you only call it once and then store it in a variable that you can refer to when looping. You do not call it inside a loop.

SPTreeView Control by default shows all the lists, document libraries & Sites in the Current Context (Web), if you want to show only the Sites from the Root of your sitecollection. Open your master page using SharePoint Designer and find “SPHierarchyDataSourceControl” and update it to look like below element.

<SharePoint:SPHierarchyDataSourceControl runat=”server” id=”TreeViewDataSource”  IncludeDiscussionFolders=”false” ShowDocLibChildren=”false” ShowFolderChildren=”false” ShowListChildren=”false” RootWebId=”INSERT YOUR ROOT WEB GUID HERE” />

 Make sure that you remove “RootContextObject” attribute, RootContextObject property value overrides “RootWebId” property.

Recently when I tried customize “SPTreeView” I came accross below error

Could not bind to the ‘EncodedName’ property (specified by TextField) while data binding TreeView.  Please check the Bindings fields.

 The problem is I was trying to assign ID of “SiteMapDataSource” to SPTreeView Controls’ “DataSourceId” property, when I updated the “DataSourceId” property to SPHierarchyDataSourceControl Control ID SPTreeView works fine.

When I tried to re-attach a page to its pagelayout I get an SPD error message saying the page layout could not be found though the page layout exists.

I was not able to figure out what caused this problem but I was able to fix this issue by updating page layout URL manually.

1. Make sure your page reattached (click Ok when SPD prompts page was reattached to different pagelayout)
2. Using browser go to your Page Library
3. From “Actions” menu select “Open with Windows Explorer”
4. Copy the Page to local hard disk (Drag and Drop)
5. Open the Page using WordPad (Page has special Characters) and find “<mso:PublishingPageLayout msdt:dt=”string”>” element and update the Path to your original PageLayout Path.
6. Upload back to your SharePoint Pages Library

Whenever I try to edit pagelayout by double clicking a page and “Edit Pagelayout” I get a weird message. The URL SharePoint Designer (SPD) prompts is not relative path and moreover it points to my production enviornment. 

If you click “Yes” SPD will prompt for production domain credentials and if I have already authenticated with that domain, SPD directly opens the pagelayout from production enviornment “It really gets Scary”.

I have seen this behaviour since I refreshed my development environment with a production backup copy (using stsadm backup/restore commands) that explains this weird behaviour then I tried to recreate my development enviornmnet with stsadm Import/Export commands but the problem still didn’t go away. 

Resolution 1

This problem can resolved by simply detaching and reattaching to page layout using SPD.

The above resolution works fine but the problem is you have to do this for every page you want to edit and moreover without your knowledge you might end up editing Production layout pages.

Resolution 2

Vincent Rothwell has nice little tool which recursively traverses all the Pages in all sites in your SIte Collection and updates PageLayout path property.

Caution : The above tool updates all the pages in the SIte Collection, that means if you have dettached pages they will be attached your changes will be lost.

Resolution 3

Gary Lapointe has stsadm command extension to fix PageLayout URL’s

 gl-fixpublishingpagespagelayouturl has scope option where we can apply the fix for Page, Web, SIte or WebApplication.

Installing Service Pack 1 broke Advanced Search webpart on my development environment.  Microsoft has a  hot fix for this.

http://www.harbar.net/articles/postsp1.aspx has a nice list of post SP1 hot fixes along with their build numbers.

http://technet.microsoft.com/en-us/library/cc721660.aspx has the list of most common MOSS Events and Error Messages.

SharePoint Crawler converts links to lower cases before indexing, this is OK if you are not indexing Complex URLs. But this could be a problem if you index pages with query string parameters and if parameters are case sensitive.

Example : if you have a Content Query Webpart (http://www.andrewconnell.com/blog/archive/2008/02/18/Subclassing-the-Content-Query-Web-Part-Adding-Dynamic-Filtering.aspx)  or Data view webpart with filters (passed by Querystring).

In above example “Division” is case sensitive, SharePoint Crawler will not be able to index this webpage as CQWP will throw exception when it access same page with
http://liware/sites/publishing/widgets/pages/default.aspx?filter1field=division&filter1value=europe url.

The above image is from Andrew Connell Blog (http://www.andrewconnell.com/blog/archive/2008/02/18/Subclassing-the-Content-Query-Web-Part-Adding-Dynamic-Filtering.aspx)

By default configuration SharePoint doesn’t index pages with Complex URL’s (Query Strings).  In most cases (intranet sites) this is acceptable but for Internet websites we would like MOSS to index all our dynamic pages also.

1. Go to Shared Services Provider and Select “Search Settings”
2. Select “Crawl Rules” and Create a New Crawl RuleEnter path of your SharePoint Site. If you have only one site with complex url’s then it is recommened to enter path of that site.Make sure you select “Crawl complex URLs (URLs that contain a question mark (?))” and “Crawl SharePoint content as Http pages.” If you don’t select “Crawl SharePoint content as Http pages”, SharePoint will not index Complex URL’s (even if “Crawl complex URLs (URLs that contain a question mark (?))”  is checked )

Drawbacks when “Crawl SharePoint content as Http pages” is checked

1. Item level permissions are not stored;  that means users might see results even though they don’t have permissions to link/item/page.
2. Crawler indexes all  application pages (_layouts folder ). Make sure you have a crawl rule (like *://*/_layouts/* ) to exclude all _layouts pages.
3. Crawler treats the SharePoint Site as a regular Web Site and follows only the links it indexed (just like any other external Search Engine ). If you create a new page and publish it but didn’t link it anywhere in your site this page will not be indexed.
4. No metadata will be indexed.

I often get ” The search request was unable to connect to the Search Service.” on my development environment. Though Office SharePoint Server Search and Windows SharePoint Services Search windows services are running fine.

Fix

1. Restart “Office SharePoint Server Search” and “Windows SharePoint Services Search” Windows Services
2. do IISRESET

This problem can also occur in new environments where these services are not configured properly

1. Go to Operations tab in Central Administration
2. Select “Services on Server” from Topology and Services
3. Select your Indexing/application Server from the server menu and make sure “Office SharePoint Server Search” and “Windows SharePoint Services Search” services are started.

Update (July 22nd 08)

More Error messages

• Your search cannot be completed because of a service error. Try your search again or contact your administrator for more information.
• Error HRESULT E_FAIL has been returned from a call to a COM component.

Fix

• Check Event Logs for Error Messages
• Make sure your Search Databases are up and accessible to MOSS Search Service.