The SharePoint 2010 Feature Solution Framework : Writing Your First Feature and Solution (part 1) - Create the Project

Assuming that you're a developer, the previous exercise on dropping and creating a WebPart was just too easy for you. Let's sharpen your claws and write your first solution and feature in Visual Studio 2010.

Like any other project, you first create the project. Next, you add functionality into your project and then you deploy and debug. Finally, you may have to worry about things such as versioning, upgrades, and so forth.

1. Create the Project

On your SharePoint development machine, start Visual Studio 2010. Then, click File => New Project, and look for the SharePoint 2010 group on the left, as shown in Figure 1.

Figure 1. The various SharePoint project templates

There are so many different kinds of SharePoint 2010 projects you can create. Usually, I like to create a project that mimics a business need such as Invoice authorization or time sheet. I don't like to create solutions that have technical meanings such as "The TimeSheet List Definition" or "The Timesheet WebPart". One .wsp can contain many SharePoint artifacts. It makes sense that you should hand over a timesheetfunctionality.wsp rather than five or ten .wsps that deploy parts of timesheet functionality. In that vein, I find myself creating the Empty SharePoint Project the most, so create a new "Empty SharePoint Project", and call it "HelloWorld".

As soon as you try and create your new HelloWorld project, Visual Studio will present you with the dialogbox shown in the Figure 2.

Figure 2. Debugging site and trust level for your SharePoint project

There are two questions being asked here. The first is, which local site do you want to use for debugging? This is the same machine that you are running SharePoint on. Some may wonder why Visual Studio has to ask such a silly question, because after all this is always your local machine. The reality is, sometimes you may have alternate URLs setup even for your local site, and that may be important in certain development tasks. Secondly, the site collection you intend to debug your code on may not be a root level site collection. Finally, if you have multiple web applications, this tells Visual Studio which w3wp.exe process to attach to for debugging. So you see, it's not such a silly question after all.

Providing the URL tells Visual Studio which web application you will debug your code on, and which w3wp.exe process visual studio should attach itself to during debugging, so you as a developer can now create a breakpoint, hit F5, and your breakpoint just hits. Something your fellow .NET developer brethren have been doing since 2000 is now finally available out of the box to SharePoint developers.

That was my marketing side talking. Although in simplistic scenarios F5 debugging will work, in many situations you will still find yourself attaching to processes. For example, sometimes your code may not run inside w3wp.exe. It may run under a separate EXE called SPUserCodeService.exe.

A farm solution is what used to be a solution in SharePoint 2007. Basically, it had unfettered rights to your SharePoint farm, so it could do anything. Sounds like a good proposition, but this created an immense headache for the two poor farm administrators in your organization who were then expected to somehow review every line of code being deployed to the server. A task they intend to get around to doing right after they solve world peace and hunger. Frankly, it is unreasonable to expect two overtaxed IT Pro people to review every single developer's code. Plus since some developers can be really crafty, custom code, while being necessary, is the number one reason for support issues on SharePoint in general.

In response, Microsoft came out with the concept of sandboxed solutions, sometimes also referred to as user solutions or user code. Put simply, a sandboxed solution is what runs inside a secure sandbox. It runs inside a separate process from W3WP.exe, and it is protected by a CAS policy, so you no longer have to craft custom CAS policies. Also, in addition to being more secure, it is also more easily monitored.

Being more restricted, secure, and being more easily monitored, sandboxed solutions can now be deployed with more confidence. Thus, they are now deployable and can be activated right through the site collection. The Farm Administrator doesn't even need to be bothered, because he is monitoring the solution anyway.

Now that the HelloWorld project is created, let's examine the structure of the project that is created for you. You can see this structure in Figure 3.

Figure 3. The HelloWorld project structure

There are some standard Visual Studio-like nodes here, and a few interesting things that are typical to a SharePoint project.

The Properties and References area are much like any other Visual Studio project, so I won't bother explaining those too much. However, you should poke around and see what's inside them. Also, there is a strongly named key called key.snk. Sometimes, especially when working with farm solutions, your code will go into the GAC. Therefore, it must be strongly named. You should replace that key.snk with a standard yourcompany.snk in real world projects, but for use and throw code, key.snk is just fine.

Other than standard .NET-like nodes, there are two nodes specific to SharePoint development. These are Features and Package.

The Feature is a container of various defined extensions for SharePoint. It's a set of XML files which are deployed to web front ends that can be bundled in site definitions or individually turned on in SharePoint sites. Put simply, a feature is something you activate on either the farm, web application, site collection, or a site. By activating a feature on any of these four scopes, you add new things into SharePoint that are logically bundled together by you. What can those things be? Things such as new WebParts, list definitions and instances, event receivers, or content types. You will discover many of these various extensions for SharePoint, which.