Irrespective of what platform we work on, as developers, it’s unlikely that we are ever satisfied with the basic toolset we are given to work with. While Visual Studio can hardly be called basic, there is no doubt that we, as a breed, always seem to find something to complain about or wish for.

Back of the Queue …

And if there is one group of developers who have been stuck at the back of the queue when it came to handing out development tools, it’s undoubtedly SharePoint developers. Not only did SharePoint 2003 have no developer tools to speak of, but there was barely a deployment framework. SharePoint 2007 introduced the Features and Solutions Framework, which made it much, much easier to add functionality to a SharePoint Farm, but the Visual Studio toolset was still, to put it politely, basic. In my humble opinion, it was only thanks to the likes of Carsten Keutmann and his wonderful WSPBuilder  tool, and others tools like Visual Studio extensions to Windows SharePoint Services (VSeWSS), that SharePoint developers were able to actually do anything productive. Without those tools, half the time expended  on developing SharePoint customisations seemed to be actually spent copying files around, attaching to processes, recycling application pools, adding DLLs to the GAC, and so on. Not very productive.

Have things got better with SharePoint 2010? Absolutely.

Is it perfect? Definitely not, but then again, nothing is.

However, I feel it’s safe to say that the tools which now come with Visual Studio 2010 for SharePoint development are both  comprehensive and easy to use. So, in this article, we take a look at the development environment for SharePoint in Visual Studio 2010. There will be explanations and examples, but this is primarily an overview of what is currently available to SharePoint developers to make their lives easier.

In order to appreciate what a big leap ahead Visual Studio 2010 is for SharePoint Developers, we’ll take a look at some of the new tools by building a Custom WebPart for SharePoint. It may not be something that you’ve built before, but it’s something that most developers are aware of, and something that everyone tends to associates with SharePoint.

Building Your First SharePoint 2010 Solution

Before we get started, there are a few things you’ll need to be aware of first…

Prerequisites

In order to make full use of all the capabilities of the VS2010 SharePoint Development Tools, you need to install VS2010 and SharePoint 2010 onto the same machine. This can be a real or Virtual Machine, and thankfully it doesn’t now have to be a Server OS, though it must be an x64 OS. There are instructions available on how to deploy SharePoint 2010 onto Vista or Windows 7, and it’s good to see that all versions of VS2010 contain the SharePoint Toolset.

New Project Templates

Now we have our environment setup, we obviously need to create a project. When you open the New Project dialog in Visual Studio 2010, you will see a new category of SharePoint templates, under which you will see a number of project templates ranging from Empty SharePoint Project to Import SharePoint Solution Package. We won’t be going to go through every single one, and for our example we’ll just start with an Empty SharePoint Project as shown in Figure 1:

Let’s name the project ‘Demo.MyFirst2010Solution‘ and click OK.  We now get another dialog, like the one seen in Figure 2 (below), asking us to specify the site and security level for debugging.  Additionally it asks us if we want to deploy our project as a sandboxed solution. Let’s briefly discuss what solutions are in generally, and specificallty what exactly sandbox solutions are.

Sandbox Solutions and Farm Solutions

To start with, a solution is a package of functionality which you can deploy to a SharePoint installation to provide enhancements to the OOTB (Out Of The Box) functionality. It can contain DLLs, XML files, ASPX files, media files, or whatever else it is that you want to deploy to the SharePoint Site or Farm.

A solution package is actually just a CAB file with a WSP extension that also includes a manifest.xml file which tells SharePoint where to deploy the various solution components. This framework is described in more detail on MSDN. If you ever want to peek inside a WSP file, a free compression application like 7-Zip can open them, or alternatively you can just change the extension to CAB and then browse the contents using Windows Explorer.  In multi-server farms, the SharePoint infrastructure looks after deploying your solution, so you only have to deploy to the farm once, and SharePoint knows how to propagate your solution components to all the relevant servers in the farm.

So what is a Sandboxed Solution? This is a new feature which allows SharePoint farm administrators to monitor and control the operation of solutions, which can be very handy. Basically, if a developer writes code which threatens either the stability or availability of the farm by consuming excessive resources, SharePoint can shut down that code and refuse to run it!

This sounds like a good thing, and it is but there is a price to pay; the functionality available to Sandbox solutions is limited. For example, they cannot access resources on remote computers,  they cannot access content in other Site Collections, and they cannot write to the file system. MSDN has a summary of the limitations, if you need to know more.  However, there are means both fair and foul to legitimately get around these boundaries , which are also well-summarized on MSDN .

The confines imposed by Sandbox Solutions means that some projects simply cannot be deployed as such. You may have noticed another type of project earlier called a Visual WebPart, and it’s a perfect example of a project which simply cannot be created as a Sandbox solution. This is because a Visual WebPart Project is really just a wrapper around an ASCX control which exists on the file system and, as just mentioned, Sandboxed solutions can’t write to the file system directly. 

So, some things you can build as Sandbox solutions, and some things you can’t. As a general rule for the benefit of your SharePoint environment, you should start out aiming to write a Sandbox solution and, if your design means you can’t meet the requirements of the sandbox, consider a ‘hybrid’ approach next. If that still won’t cut it, then you probably have to move to a Farm Solution, which is the same as a solution in SharePoint 2007.

Back to the New Project

Since we’re going to build a WebPart, let’s now add a new WebPart item to our project and call it MyFirst2010WebPart. When you’ve done this, you’ll find that VS2010 has done more than just add a C# file for your WebPart – it’s done a whole lot more. It’s actually added the following:

• A file within the MyFirst2010WePart folder called Elements.xml
• A file within the MyFirst2010WePart folder called MyFirst2010WePart.cs
• A file within the MyFirst2010WePart folder called MyFirst2010WePart.webpart
• A folder called Feature1 within the Features Folder
• A file within the Feature1 folder called Feature1.feature
• A file within the Feature1 folder called Feature1.Template.xml

The Elements.xml file is known as an Element Manifest file, and is used by SharePoint to deploy your components. If you open the Elements.xml file, you will see a bunch of XML as shown in Figure 3, which contains some SharePoint Module XML. If you don’t known what this means, it’s actually very simple: A Module is a declarative way of loading files into SharePoint, and this particular Module is loading the .webpart file in your project into the WebPart Gallery, whose Url is _catalogs/wp.

The MyFirst2010WePart.cs file is just your C# code containing the logic for your webpart, which gets compiled into a DLL and put into the Solution WSP file. The DLL does not get mentioned in the Element Manifest, but it does get included in the Solution Manifest file. The MyFirst2010WePart.webpart file is an XML declaration like in Figure 4. Notice that there is a placeholder token – $SharePoint.Project.AssemblyFullName$ – which will be replaced by the full assembly name at build time. You can also edit the Title and Description, as these are just properties that will appear in the WebPart gallery list in the SharePoint UI itself, and  do not affect the operation of the WebPart at all.

The Feature1.feature file in the Feature folder is one that deserves a little more attention. If you double-click on this, you won’t see the file contents – you will see a Design surface instead, which is part of the great new Feature Designer in VS2010. If you’re not familiar with SharePoint, you may be wondering what Features are all about, so let’s have a very brief introduction to them.

The SharePoint Feature Framework

Features were introduced into SharePoint 2007 as a way of adding enhancements to the OOTB SharePoint Experience. The Feature Framework is now so prevalent in SharePoint that just about everything uses it to deploy additional functionality into a SharePoint Farm: SharePoint Designer, InfoPath… the whole Publishing Infrastructure. The great thing about features is that they can be switched on and switched off very simply through the SharePoint UI.  You can also run code when you switch a feature on and off, which makes them extremely flexible and powerful.

At its most minimal, a Feature consists of a simple XML file which must be called feature.xml, which is what Feature1.Template.xml represents: a template on which the feature.xml file will be built. A feature.xml file will often point to an Element Manifest file which we have already mentioned. Our Elements.xml file contains the Module XML from figure 3, which automatically deploys the MyFirst2010WePart.webpart file. In SharePoint 2007 and VS2008, you had to hand-crank these feature files unless you used something like WSPBuilder or VSeWSS to help you, but even with these you had no designer to make your life easier.

The Feature Designer

The Designer, in combination with the Properties Windows, allows you to graphically build your feature. If you take a look at figure 5 above, you’ll see a few fields which you can enter information into. The Title and Description boxes are fairly self-explanatory, and the Scope field allows you to specify at which ‘level’ in SharePoint your feature will be activated (again, see MSDN for more details about scopes). For Sandbox solutions the only two scopes allowed are Site or Web. If you play around, you’ll find that the Properties window allows you set a host of other details about your feature.

In Figure 5 there is a pane called ‘Items in the Solution’;  you will see any items you haven’t selected for your feature and those items not in any feature in here.  Those items which will be included in the feature appear to the right hand side of that pane. To get any file to appear in the designer you need to set the Deployment Type property of the file itself. For example, if you select the MyFirst2010WebPart.webpart file in the Solution Explorer, you see in the Properties Windows, Figure 6, that the Deployment Type is ElementFile. There are many Deployment Types which dictate how the file is used when building the Solution Package and where the file is finally deployed to, and a full list of Deployment Types is available online.

Debug and Deploy

So, we’ve used the Designer and we now have our feature ready to be debugged and deployed. In SharePoint 2007 we would now package up our feature using WSPBuilder or something similar, and then deploy to our SharePoint Farm. In order to debug we would have to “Attach to Process …” and deploy any debug files to the GAC or bin folder in order to guarantee proper debugging. Basically, it was a pain in the neck and a waste of time.

By comparison, debugging with VS2010 is now simply a matter of pressing F5 – VS2010 does the rest. It’s just as easy as debugging a normal ASP.NET application. VS2010 actually builds your project, packages it up into a WSP file, recycles the IIS Application Pool, retracts any previous versions of the solution, deactivating any features, deploys the WSP file to the SharePoint Solution Store, instructs SharePoint to Deploy the Solution, and activates any features. Finally, it creates a browser session which ensures a w3wp.exe process is running, and hooks the debugger up to the process for you, and then waits for you to start debugging. For SharePoint Developers, this is truly a thing of beauty.

When you stop debugging, everything is then reversed, and your whole solution is torn down so that the farm returns to its previous state. If you have specific deployment or debugging needs, you can set up your own Deployment Profiles for the project to customize what actions you want carried out when you hit F5.

Finally, when you are ready to deploy to the production farm, just right-click on your project, and select Package, and your solution package is built for you, ready for the final destination.

Summary

The most important thing to take away from this article is that SharePoint Development is now finally mainstream in Visual Studio. The fact that the tools are not an add-on or only available in certain editions is a big tell.  However, as with all things, there is always room for improvement, and already developers are enhancing the OOTB tools: there are the Visual Studio 2010 SharePoint Power Tools and, most impressively, the Community Kit for SharePoint: Developer Tools Edition, which has a host of very useful extras.

As I mentioned at the start of this article, I’ve only given you an overview of the bright new future ahead of SharePoint development. I haven’t even touched on a bunch of tools and components that make the whole development of SharePoint solutions a world easier than it was before. While I mentioned SharePoint Designer (which is now a great, and free, tool), there’s also SPMetal (for creating Entity Models of SharePoint for use with LINQ for SharePoint), the three Client Object Models for Silverlight, Javascript and Remote Access, and also the REST API.

All in all, at the risk of overusing a metaphor , I think it’s safe to say that SharePoint Development is finally emerging from the Dark Ages, where the alchemists and phrenologists ruled, to at least the Renaissance Period where, even if you’re not a Leonardo, you have a chance to easily create fantastic SharePoint sites! Things are definitely looking up, and people taking a look at SharePoint will now be able to see it as another first-class, accessible Development Platform where they can apply their existing .NET skills.