Manage a solution in Visual Studio 2010

Visual Studio has some nice built-in support for developing custom SharePoint solutions. I personally tend to use the SharePoint Module project template, so this post will describe its workings as well.

First the most straightforward: how to make a solution sandboxed/farm level? In the project properties there’s one called Sandboxed solution. Simply set it to true to make your solution sandboxed, otherwise false.

To customize the features which will be added to your package simply open the Package folder. It has a nice editor in which you can add and remove features in your solution.

To deal with assemblies just select the Advanced tab on the package editor surface. There you can add assemblies from your solution output, or from other locations as well. You can also specify if you want individual assemblies to get deployed to the GAC or just to the web application.

You can also map folders in your project to their counterparts in the SharePoint 14 folder (this is only allowed in farm level solutions). Just right click on your SharePoint project and select “SharePoint mapped folder” from the Add context menu. To deal with resources add a mapped folder to the SharePoint Resources folder, and put your .resx files in there. Make sure to set their Build Action to Content, otherwise you won’t be able to use them.

All of the settings I specified above will be merged into a single file called Manifest.xml. If you feel brave, you can edit this xml file by hand. You just need to enter  the package editor, select the Manifest tab, expand Edit options, and click on the link  starting Overwrite generated XML. Visual Studio will try to persuade you not to do so, but this change is reversible any time. If you clicked through these items, the package editor will be disabled, and you can edit the XML file by hand. The schema is pretty self-explanatory, so I wouldn’t describe it here.

Manage SharePoint object life cycle by using the Dispose API

Since the SharePoint object model uses a lot of unmanaged objects you should dispose them after you’re done working with them. The standard way in the .NET Framework to do so is using the IDisposable interface – so is in SharePoint.

As a standard rule of thumb: whenever you create a new instance of an SPSite or an SPWeb, you should dispose it. The same holds true if you acquire your SPSite or SPWeb through an indexer, a property or whatever EXCEPT when you get the instance via the SPContext class. SharePoint manages the current SPContext, and you should never release it. There’s one other exception: the disposal of SPSite.RootWeb is managed internally, you should not release it.

Now the preferred way is to use a using statement, like this:

using(SPSite site = new SPSite(“mysiteurl”))
{
using(SPWeb web = site.OpenWeb())
{
//do stuff here
}
}

The using blocks will be converted to appropriate try and finally blocks, so your unmanaged resources will be disposed. Of course you can use the try/catch/finally or try/finally pattern explicitly. In this case you should dispose your objects in the finally block, but be sure to check for null references first.

One last thing to consider: since Response.Redirect by default does not play well with finally blocks (e. g. finally won’t be called) you should dispose your objects explicitly before calling Response.Redirect.

Check out this series of blog posts about best practices with SharePoint and IDisposable.