I would like to reference to an old post that appeared in 2007 on http://blogs.msdn.com/sharepoint, that mentions the SharePoint debugger feature. I use it quite a lot and i am sure a lot of people don’t know about its existance. Its a relatively simple feature that shows up in the SiteActions menu, opens a page which tries to launch the debugger. Using this feature, you don’t need to run iisapp, find the right PID and attach that process to your debugger. Make sure to edit the web.config to allow debugging.
link to the article: http://blogs.msdn.com/sharepoint/archive/2007/04/10/debugger-feature-for-sharepoint.aspx
the link referenced to the codeplex source doesnt work anymore. Use the following link instead:http://www.codeplex.com/features/Release/ProjectReleases.aspx?ReleaseId=2502
SPDisposeCheck is a tool to help you to check your assemblies that use the SharePoint API so that you can build better code. It provides assistance in correctly disposing of certain SharePoint objects to help you follow published best practice. This tool may not show all memory leaks in your code. Further investigation is advised if you continue to experience issues. It’s a must for every SharePoint developer!
Read more about it here:
As I had problems with the way events worked, I wanted to know more about the way they worked. below is bit of information about events that is good to know:
There are two different kinds of events: Synchronous and Asynchronous events.
- Synchronous events
- End with -ing (ItemAdding, ItemUpdating)
- Block the code as long the events arent finished
- Can (thus) make use of Session vars (HttpContext.Current is available), because they run in the same session
- Can be used to prevent the event being finished. For example, with the ItemUpdating event you can verify the content being updated. Is the update not valid, the SPItemEventProperties.Cancel can be set to true and the SPItemEventProperties.ErrorMessage can be filled with an error message. This error message will not be displayed, but is written to the logfile. An error page will appear.
- dont contain the SPListItem in it’s SPItemEventProperties so when you want to make changes to any of it’s field you need to make use of the SPItemEventProperties.AfterProperties (see message below). In the case of itemUpdating, the “old” SPListItem will be used
- Asynchronous events
- End with -ed (ItemAdded, ItemUpdated)
- Dont block the code.
- Can’t (thus) make use of the Session (HttpContext.Current is null, because code is run in another context)
- Can’t be reverted; When these events are fired, the item is already added, updated or deleted.
- contains the SPListItem. Changes can be made if you want to. This fires the (for example) ItemUpdating and ItemUpdated event. This can be turned off by using this.DisableEventFiring();
- When creating a new list, events like FieldAdded and FieldAdding are not fired!
Some time ago I tried to alter a field of a SPListItem right after the moment that the item has been created. A var was stored in the Session so it could be used on the newly created SPListItem (itemAdded).