Welcome to my blog, stay tunned :
Home

Top 10

I've written a series of Top 10 stories (top 10 tools, top 10 good practices etc..). Here are all the posts belonging to that series

My top 10 tools for a better SharePoint development experience

Hi,
The purpose of this blog post is to present some tools that I’m using in my day to day SharePoint activities. I will not talk about the very rich Microsoft tools such as SharePoint Designer, InfoPath et…I’d rather focus on tools that really help hardcore developers to be more efficient in both development and troubleshooting.
This list of tools can probably be largely extended, so don’t hesitate to add comments to present your favorite tools.

CKS Dev

Available at http://cksdev.codeplex.com/

My Top 10 tests when testing custom SharePoint webparts

1. Logging in with a Visitor only profile
Often, developers work on development environments where they have full permissions. Because of that, they might not notice some permission issues. Having a test account with lower permissions helps identify such problems before going further in the deployment cycle.

Here are a few scenarios when a visitor role would encounter problems:

•Somewhere during its the execution, the webpart accesses a list with unique permissions on which visitors have no permission.

My top 10 sanity checks when performing SharePoint code review

1. Checking for memory leaks

Memory leaks are the big evil but most of the times, it is important to have a pragmatic approach when hunting them .

First, a short reminder of what a memory leak is: a memory leak is a space in memory that was not released after use. Before hunting them, it is important to focus on the parent process that executes them. Sometimes, I see people trying to find memory leaks in PowerShell scripts…While it is always a best practice to release the memory as soon as you are done with it, this is not an absolute necessity when dealing with scripts since they are most of the time executed during a short amount of time and when PowerShell.exe stops running, the memory associated with the process gets released automatically.

So, I would definitely not spend time in a large-scale SharePoint implementation on chasing memory leaks in PowerShell scripts.

Here are the top 3 components that must be monitored closely according to me:

The Timer Jobs: since they are executed every xx minute/hours/days/weeks, they can, therefore, regularly cause new leaks. Moreover, they are executed by OWSTIMER, a permanent process running on the server(s), thus not releasing memory until it stops or until you explicitly dispose of your objects (simplification here…).

Farm deployed WebParts/WebControls: and basically all the controls that are handled by w3wp.exe for the same reason as the above. Although w3wp.exe are usually recycled automatically by IIS, it’s important to make sure they are not recycled unexpectedly because of your components.

SandBoxed Solutions:again, they are executed by permanent processes running on the server(s). With SandBoxes, SharePoint already controls the resources used but it’s still necessary to review the code.

Of course, to find those memory leaks, it’s always handy to have a tool and this tool is quite famous now in the SharePoint world and is called SPDisposeCheck.

http://archive.msdn.microsoft.com/SPDisposeCheck


2. Checking the number of SPSite and SPWeb objects that are instantiated

As you probably know, instantiating SPSite & SPWeb objects require a lot of resources, therefore, I tend to instantiate them only when absolutely required. So, I’m looking for patterns like this one:

class Utils  
{  
  public string GetWebTitle(string url)  
  {  
    using(SPSite Site = new SPSite(url))  
    {  
      using(SPWeb Web=Site.OpenWeb())  
      {  
       return Web.Title;  
      }
    }  
  }  
  public string GetWebList(string url, Guid listid)  
  {  
     using(…)//same as above  
  }   
}