Below, I am making a list of the tools I use most frequently for MOSS development, diagnosis and some maintainance.

SharePoint Manager 2007

http://www.codeplex.com/spm

This tool is a MOSS swiss army knife. It traverses the MOSS object model and displlay the properties for a vast number of MOSS objects. The tool also allows the user to make changes on the spot and commit the changes to MOSS. I can't emphasize enough how good this tool is.

U2 CAML Tool

http://www.u2u.info/Blogs/Patrick/Lists/Posts/Post.aspx?ID=1315
This tool makes building and testing CAML queries a simple task. It connects to MOSS and allows you query build live queries and test them accordingly.

Web Service Studio 2.0

http://mattharrah.com/blog/web-tools/net-web-service-studio-20/
This tool allows you view SharePoint through it web services. I use this tool for verifying data, extracting xml to verify and assimilate MOSS objects. Through it you can invoke webmethods interactively by providing a WSDL endpoint. The tool fetches the WSDL, generates .NET proxy from the WSDL and displays the list of methods available. Then you can invoke any method (with custom input parameters). The SOAP request is sent to the server and the response is displayed in the UI.

WSP Builder

http://www.codeplex.com/wspbuilder
This tool This tool is used for create web solution packages (wsp) from a folder structure. There is also a Visual Studio Add-in which allows you to build a wsp for a project at a time. This tool saves hours of configuration and testing per project. This tool is a must for building SharePoint solutions.

FireBug (for FireFox)

https://addons.mozilla.org/en-US/firefox/addon/1843

This tool integrates with Firefox to put a wealth of development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page. It allows you to explore and modify the document object model (DOM) of a Web page. This includes the styles, style sheets and other resources. The Developer Toolbar can be pinned to the Firefox browser window or floated separately.

IE Developer Toolbar

http://www.microsoft.com/downloads/details.aspx?familyid=e59c3964-672d-4511-bb3e-2d5e1db91038&displaylang=en

This tool allows you to explore and modify the document object model (DOM) of a Web page. This includes the styles, style sheets and other resources. The Developer Toolbar can be pinned to the Internet Explorer browser window or floated separately.

I will add more tools as I remember and/or encounter them. I will use the MOSS Tools label.

I recently had a meeting with a client where it was asked if SharePoint 2007 (MOSS) still suffered from the SharePoint 2003 limitations. I began testing and ran into no limitations. I stopped at 190 fields successfully. I also tested the 190 fields with content types, and adding and editing documents using the content type.

Background

In SharePoint 2003, the following limitations were well known (1):

• 64 Single line of text and Choice (drop-down menu or radio buttons)
• 31 Multiple lines of text and Choice (check boxes (allow multiple sections))
• 32 Number and currency
• 32 Hyperlink
• 16 Date and time
• 16 Lookup
• 16 Yes/No
• 8 Calculated

Findings

I found Microsoft literature specifying the following “guidelines for acceptable performance” for columns (2):

• 2,000 per document library
• 4,096 per list

“This is not a hard limit, but you might experience library and list view performance degradation as the number of columns in a document library or list increases.”

I found a blog article where Ishai Sagi tested the performance of creating 2000 text fields. Here is a summary of his findings:

I looked into SharePoint 2007 to figure out exactly how Microsoft overcame the limitations in SharePoint 2003. SharePoint has a table called “AllUserData” where they have the following fields:

• 8 datetime (DateTime)
• 12 float (Number, Percentage)
• 16 int (Integer)
• 16 bit (Boolean)
• 32 ntext (Note)
• 64 nvarchar (Text, Url, Choice)
• 8 sql_variant

In a nutshell, if the limit of any of the column types is reached, SharePoint uses a second row to begin populating the data. The new row will have a field called rowOrdinal incremented to 1. Therefore, if the column once again exceed their limit, the rowOrdinal will be incremented to 2 and so on.

1 - To read more about the SharePoint 2003 limits: http://support.microsoft.com/default.aspx?scid=kb;en-us;823555

2 - To read more about the SharePoint 2007 (MOSS) limits: http://technet.microsoft.com/en-us/library/cc262787.aspx

3 - To read more about the performance testing of columns: http://www.sharepoint-tips.com/2006/06/sharepoint-2007-column-limits.html

Several blogs out there talk about the need to close and/or dispose of the SPSite and SPWeb objects. I took this to heart but then I started receiving the occasional error stating:

"Trying to use an SPWeb object that has been closed or disposed and is no longer valid."

The purpose of this blog entry is to clear this up (at least for me). The following link is to Microsoft's documentation on this matter: http://msdn2.microsoft.com/en-us/library/aa973248.aspx

In summary:

• If you create SPSite object using the "new SPSite()" constructors (any constructor override), then you need to call the "SPSite.Dispose()" method.
• If you create the SPSite object using SPControl.GetContextSite(), then you should NOT dispose of the object.

This is Microsoft's explanation as to why you should not dispose of the object when instantiated through using SPControl.GetContextSite():

"Because the SPWeb and SPSite objects keep an internal list that is derived in this way, disposing of the object may cause the SharePoint object model to behave unpredictably. Internally, Windows SharePoint Services enumerates over this list after page completion to dispose of the objects properly."