If you have used the Visual Studio 2010 SharePoint Developer Tools you have probably noticed that there are multiple SharePoint Project Item Templates to create Web Parts from. Find out which of them make the most sense in what scenarios.

The Visual Studio 2010 SharePoint Developer Tools are the new tools for SharePoint developers that simplify the process of creating SharePoint solutions and improve developer productivity. The tools provide a number of templates for various SharePoint assets among which for Web Parts. Out of the box the tools contain two templates for creating Web Parts: Web Part and Visual Web Part.

Shortly after the release of Visual Studio 2010, Visual Studio 2010 SharePoint Power Tools have been released. Those Power Tools contain an additional number of extensions to further help developers build SharePoint 2010 solutions. One of the new pieces is the template for the Visual Web Part (Sandboxed).

Alongside the tools and extensions released by Microsoft, a number of community-driven tools and extensions have been created and bundled under the name of Community Kit for SharePoint: Development Tools Edition (CKS:DEV). CKS:DEV also introduces a number of templates for creating Web Parts: Fluent UI Visual Web Part and Contextual Web Part.

As you can imagine all these templates are different and created with a different purpose in mind. So when to use which one?

Web Part

Standard: Yes Sandbox compatible: Yes

The Web Part SPI Template is the most basic template for creating Web Parts for SharePoint solutions. It inherits from the System.Web.UI.WebParts.WebPart class and gives you a blank canvas for creating custom Web Parts. While it offers great flexibility, it requires the most work, since everything has to be done imperatively.

Overview

Pros:

• available out of the box, doesn’t require any custom tools to be installed on dev machines
• offers the greatest flexibility
• can be used for Web Parts in Sandboxed Solutions

Cons:

• everything has to be done from scratch
• everything has to be done imperatively what might have negative impact on productivity
• implementing complex UI difficult and time consuming

Ideal for:

• Web Parts with no/little UI
• Web Parts with controls generated dynamically
• Web Parts with dynamic rendering
• extending existing Web Parts
• deploying preconfigured Web Parts such as Content Query Web Part to the Web Part Gallery

Before use:

• check if no other Web Part is available out of the box to use as the base class to get yourself a head start

Visual Web Part

Standard: Yes Sandbox compatible: No

Back in the SharePoint 2003 era Jan Tielens came up with a great idea of using User Controls as UI surface for Web Parts. By loading them into Web Parts developers had the ability to combine the best of both worlds: flexibility and efficiency from visual and declarative UI development in User Controls and the power of Web Parts for providing building blocks for portals. The Visual Web Part reuses this idea and makes it available to developers of solutions for the SharePoint 2010 platform.

Although it seems very powerful at first, the Visual Web Part has two serious shortcomings. First, in order to render the UI, the Web Part has to load and instantiate the User Control. This requires the assembly which contains the Web Part to have full trust. Because the control is loaded on runtime it has to be deployed to the ControlTemplates folder in the SharePoint Root. This makes it impossible to use the Visual Web Part in Sandboxed Solutions.

Overview

Pros:

• available out of the box, doesn’t require any custom tools to be installed on dev machines
• offers great productivity when creating Web Parts with complex UI
• allows you to separate Web Part’s UI from the code making the Web Part easier to maintain

Cons:

• requires full trust to load the UI from the User Control
• uses reflection to instantiate the UI which has performance impact
• deploys the User Control to SharePoint Root what makes it impossible to use the Visual Web Part in Sandboxed Solutions
• Web Part is separated into assembly and User Control. Updating Web Part means updating assembly, User Control or both depending on the change
• Web Part contains a separate class file so in order to use Web Part properties in the User Control you have to define them twice (once in Web Part and once in the User Control)

Ideal for:

• Web Parts with complex UI although better alternatives are available (see Visual Web Part (Sandboxed))

Before use:

• consider using Visual Web Part (Sandboxed)

Visual Web Part (Sandboxed)

Standard: No (part of Visual Studio 2010 SharePoint Power Tools) Sandbox compatible: Yes

Shortly after the release of Visual Studio 2010 the CKS:DEV team came up with the idea of improving the Visual Web Part. The idea was to benefit of the ASCX file for development but instead of deploying it with SharePoint Package to use it for generating a class file that could be compiled into the assembly. This would combine the best of both worlds: it would allow developers to be productive and yet have no performance and security impact.

Short after releasing the first version of Sandboxed Visual Web Part in CKS:DEV, a similar version have been released as a part of the Visual Studio 2010 SharePoint Power Tools. The SPI template that shipped with CKS:DEV has been decommissioned and the Visual Web Part (Sandboxed) became the suggested template to use.

Overview

Pros:

• offers the same benefits as the Visual Web Part
• because no files are being deployed to the file system, can be used with Sandboxed Solutions
• as the UI is being compiled into the assembly, there is less performance impact comparing to the Visual Web Part and there are no additional security requirements
• no separate code file is used so everything is contained in a single place (assembly)

Cons:

• because the UI is generated from the ASCX file each time it’s saved, you might get caught in a loop if you reference something from the assembly that hasn’t been built yet and which cannot be built because the ASCX file hasn’t been parsed yet
• ASCX file doesn’t support replaceable parameters at the moment of writing this article

Ideal for:

• all Web Parts with (complex) UI

Fluent UI Visual Web Part

Standard: No (part of CKS:DEV) Sandbox compatible: No

The Fluent UI Visual Web Part template has been created to show you another way of editing Web Part properties. Instead of using custom Editor Pane, the Fluent UI Visual Web Part uses the new dialog UI capabilities of SharePoint 2010. This approach allows you to create richer experiences and provide more intuitive UI to the users comparing to using standard Editor Parts. The downside is that it’s pretty complex and might take you a while to understand all the different pieces that the Fluent UI Visual Web Part is using. Another downside is that the Fluent UI Visual Web Part is based on the Visual Web Part so it has the same cons for using it as the standard Visual Web Part.

Although the Fluent UI Visual Web Part is not something you will use every day, it is a great example of what can be achieved with the new UI capabilities of SharePoint 2010.

Overview

Pros:

• great sample for leveraging the new UI capabilities of SharePoint 2010
• offers head start if you want to use the fluent UI capabilities in your Web Part

Cons:

• has all the cons of Visual Web Part
• complex. Consists of many different pieces

Ideal for:

• very specific scenarios. Not something you will be using every day

Contextual Web Part

Standard: No (part of CKS:DEV) Sandbox compatible: No

One of the improvements in SharePoint 2010 is the new Ribbon-based UI. The new UI makes it easier for users to find the right functionality for their work. Additionally Ribbon controls are context-aware so they can be displayed only whenever certain functionality is applicable. This helps keep the UI less cluttered and makes it easier for the users to find specific options.

The Contextual Web Part SPI template has been made to simplify building Web Parts that interact with Ribbon and provide context-aware functionality. The template contains all the plumbing including the definition of Ribbon components, a Page Component for handling Ribbon commands and even simple icons created as an image sprite!

In order to interact with Ribbon, a Web Part must implement the IWebPartPageComponentProvider interface. Unfortunately at the moment of writing this article this interface is not supported in Sandboxed Solutions. Hopefully this will change in the future and we will be able to create more intuitive Web Parts for the SharePoint Sandbox.

Overview

Pros:

• provides great head start for building Web Parts that interact with Ribbon
• contains all the plumbing including Ribbon definition and Page Component

Ideal for:

• Web Parts that interact with Ribbon

Before use:

• be sure you understand all the pieces in the Contextual Web Part: what they are, what they do and where they are deployed to

Summary

There are multiple templates available for creating Web Parts for SharePoint 2010 solutions. Choosing the right template offers you not only head start but also helps simplify the lifecycle management of your solution and standardize your solution. For most scenarios the standard Web Part template or the Visual Web Part (Sandboxed) template are the most suitable templates to start of. In more advanced cases you might choose for the Contextual Web Part or the Fluent UI Visual Web Part template as the boilerplate for your Web Part.