Developing in SharePoint with Visual Studio: A primer

SharePoint 2007 introduced essential concepts and infrastructure to the SharePoint development platform such as the support for features and solution packages. However, the developer tools available for SharePoint 2007 were never able to keep up with the advancements in the underlying platform. This has led to criticism throughout the SharePoint 2007 product lifecycle that SharePoint as a developer platform is not yet ready for prime time and that it will not be ready until Microsoft creates a first-class development experience in Visual Studio.

The wait is over. SharePoint developer tools are included in the default installation of Visual Studio (VS) 2010 and they were designed to make developing for SharePoint 2010 much faster and easier. They are great for new developers just getting started with the SharePoint development platform because they abstract away many of the low-level details, such as creating the manifest.xml file and building a project into a .wsp file. The SharePoint developer tools also integrate commands into the VS 2010 environment that make it easy to deploy and retract the solution package for a SharePoint project during testing and debugging. Let’s look at some basic things you need to know about SharePoint developer tools in VS 2010.

First, you can’t use the SharePoint developer tools to develop solutions for SharePoint 2007. They can be used only to develop for SharePoint 2010 and future versions. If you're still required to build business solutions for SharePoint 2007, you must use one of the older tools such as VSeWSS or WSPBuilder.

Second, before you begin using the SharePoint developer tools in VS 2010, you must ensure that your developer workstation is configured correctly. In particular, you must build out your development workstation as a single-server farm running either SharePoint Foundation or SharePoint Server 2010. A key point is that they don’t work correctly on a workstation that doesn’t have a version of SharePoint 2010 installed. That's because these tools were designed to run on a computer that is acting as a front-end Web server within a SharePoint 2010 farm.

Now let’s dig into a project. Every SharePoint project is created with built-in support to generate its output as a solution package. All VS projects contain standard nodes such as Properties and References. SharePoint projects have two additional nodes: the Features node and the Package node. You use the Features node to add new features to a SharePoint project. The Features node is empty when you create a new SharePoint project using the Empty SharePoint Project template. You use the Package node to track project-wide settings related to building the project into a solution package .wsp file.

All SharePoint projects also have three special menu commands: Deploy, Package, and Retract. These menu commands are available when you right-click the top-level project node in Solution Explorer. You can run the Package command to build a SharePoint project into a solution package. You can use the Deploy command to run a sequence of deployment steps that deploy the solution package in the local farm so that you can test and debug your work. The Retract command reverses the act of deployment by retracting the solution package from the local farm.

VS also provide a set of SharePoint-specific project item templates which are known as SharePoint Project Items (SPIs). This makes it easy to create SharePoint solutions with contains common components such as Web Parts, content types, list definitions and workflow templates.

Several different project templates are available in Visual Basic and C#. When you select one of these project templates in the New Project dialog box and then click the OK button to create a new SharePoint project, this launches the SharePoint Customization Wizard. The SharePoint Customization Wizard prompts you for two pieces of information: the URL to a local site and a trust level.

When you enter the site URL in the SharePoint Customization Wizard, you must provide the URL to a site that is accessible within the local SharePoint farm. You also choose between two options: Deploy As A Sandboxed Solution and Deploy As A Farm Solution. Your choice mainly affects how the project’s solution package is deployed during testing and debugging.

I would be remiss if I didn’t mention a great utility named Server Explorer, which now includes the ability to browse local SharePoint connections. This gives you a convenient way to inspect a SharePoint site from within VS 2010 and to see the elements inside the site, such as lists and document libraries. However, the core value of VS 2010’s SharePoint developer tools revolves around developing, testing, and debugging SharePoint solutions.

To learn more about VS 2010’s SharePoint developer tools, see Microsoft’s resources at the webpage “SharePoint Development in Visual Studio.”