SharePoint 2010 Developer Tools in Visual Studio 2010

RELATED: "New Features in Visual Studio 2010" and "Using Dynamic Data in Visual Studio 2010."

Visual Studio 2010 provides powerful tools within the IDE that let Visual Studio developers use their existing skills to build SharePoint solutions. Although SharePoint is considered a development platform built entirely on ASP.NET, it's been difficult for SharePoint developers to quickly ramp up because a deep knowledge of SharePoint architecture and infrastructure is needed. This changed with the 2005 release of the Windows SharePoint Services Extensions for Visual Studio, a set of templates and tools for developers to build, package, and deploy SharePoint solutions in Visual Studio 2005 and 2008. The SharePoint support in Visual Studio 2010 makes it even easier for developers to get started with SharePoint development. Visual Studio 2010 offers visual designers, packaging and deployment support, project and item templates, and project and tool extensibility, all of which make SharePoint development simpler and faster for developers new to SharePoint.

Visual Web Parts

To learn how Visual Studio 2010 simplifies many of the mysteries of SharePoint 2010, I'll start with the visual designers. Developing Web Parts is one of the most common SharePoint developer tasks, so I'll start with the Visual Web Part designer.

To use the new SharePoint tools, start Visual Studio 2010 with elevated permissions. Select New Project… from the Startup page to display the New Project dialog box. Expand the SharePoint node and select 2010 to display the available project templates, as shown in Figure 1.

Figure 1: Available project templates

Visual Studio 2010 offers templates to support the most common SharePoint development projects. Select the Visual Web Part template and click OK to start the SharePoint Customization Wizard. The wizard prompts you for the URL of the SharePoint site to be used for deployment and debugging and lets you choose between farm and sandboxed solution types.

Farm solutions deploy to the SharePoint farm and have full access to the SharePoint API and all SharePoint resources. In contrast, sandboxed solutions deploy to the site collection, have limited access to the SharePoint API, and can only access data within the site collection. This lets farm administrators allow sandboxed solutions, which won't impact the entire farm, to be deployed to the server. Visual Web Parts can be deployed only in farm solutions, so the sandboxed option isn't available in this case.

After you create the project, the Visual Web Part opens in the default Source view. Click the Design tab to switch to a WYSIWYG view. Regardless of which view you prefer, you can drag and drop controls from the toolbox onto the designer.

Now I'll build a typical "Hello World" Web Part. Click the designer near the top and type "My Hello World Web Part." You'll notice you have all the text tools, such as font size and color, in the menu. Under the text, drag a label and button control onto the designer. Figure 2 shows what the designer will look like so far.

Figure 2: The designer so far

Double-click the button to display the code behind the form. Add a using directive to access the SharePoint object model (a reference to the Microsoft.SharePoint.dll assembly is included in all SharePoint projects).

using Microsoft.SharePoint;

Next, add the following code to the button event handler Button1_Click. This code gets the current user for the SharePoint site and sets the label to the LoginName.

SPUser user = SPContext.Current.Web.CurrentUser;
Label1.Text = user.LoginName;

With the code now complete, set a breakpoint in the first line of the event handler. It's time to deploy the Web Part and check whether it works as expected. Press F5 to instruct the project system to build the assembly, package the feature, and deploy the solution to the SharePoint site. In addition, the debugger will be attached and the browser will launch to display the SharePoint site.

When the browser launches, you're taken to the home page of the site you specified during project creation. Click on the Site Actions menu at the top left of the page, and choose More Options. In the dialog page that appears, select the item Web Part Page and click Create. Enter HelloWorld as the Name, and leave the Layout Template selected as the default. Change the Document Library to Shared Documents and click the Create button. In the header section of the new page, click Add a Web Part to display the Web Part picker. In the Categories section, select Custom, and in the Web Parts section select the Web Part VisualWebPart1. Click the Add button to add the Web Part to the page, and then click the Stop Editing button on the SharePoint ribbon. Figure 3 shows the Web Part displayed on the HelloWorld page in the browser.

Figure 3: The HelloWorld page

If you click the button, the breakpoint is hit. Press F10 to step through the code, after which your login name will display on the label control in the Web Part. If you're familiar with ASP.NET development, you can see how easy it is to get started with SharePoint development.

Workflow Designer

Workflows in SharePoint are primarily used to manage long-running processes. Although computers are designed to complete operations as quickly as possible, waiting for people to complete forms or make decisions always takes longer than the millisecond response time required to keep a CPU busy. SharePoint workflows are the ideal way to automate these manual processes.

I'll create a simple sequential workflow that adds a task to the Task list when an announcement is added. Open Visual Studio in elevated mode and select New Project. In the New Project dialog box, select Sequential Workflow. Keep the default settings in the SharePoint Customization Wizard and click Next. On the next page of the wizard, enter MyFirstWorkflow as the name for the workflow association and select the List Workflow option. List Workflows are used when you want a workflow to start when an item is added to or updated in a list or document library. (The other option is a Site Workflow, used for adding a workflow that isn't associated with a specific list or document library.) Figure 4 shows the wizard page. Click Next to continue.

Figure 4: The wizard page

Now you're asked to specify a list to associate the workflow with and which lists are used if tasks are created or entries written to the history list (a log specifically for workflows). Select Announcements in the first drop-down menu and leave the others as the default entries, then click on the Next button. The next wizard page is where you specify if and when you want the workflow to be started. Leave these at their default settings. This specifies that the workflow can be started manually by a user and will start automatically when a new item (in this case, an announcement) is created. Click Finish to complete the new project and add a workflow to the project with the options I selected in the wizard. The new workflow appears in the workflow designer.

The Toolbox should be docked on the left side of the Visual Studio IDE. If it isn't, select View and then Toolbox from the menu. There's a SharePoint section In the Toolbox with SharePoint activities. Expand it and drag a CreateTask activity onto the designer, just below the onWorkflowActivated1 activity that's already on the designer. The designer gives you feedback as to where activities can be dropped when you drag activities over valid areas.

With the CreateTask activity selected, in the Properties window (press F4 if the Properties window isn't displayed) in the lower-right corner of the IDE enter TaskToken for the CorrelationToken property. Expand the property and select Workflow1 from the drop-down menu for the OwnerActivityName. Next, click the TaskId property and click the ellipsis button (…). This displays the property binding dialog box, which allows you to bind an activity property to a field or property in the code behind the workflow so you can write code to manipulate the properties. In the dialog box, click the Bind to a new member tab, leave the name at the default value, and select Create Field. Click OK to create a new field in the code behind and bind it to the TaskId property of this CreateTask activity. Figure 5 shows the Bind dialog box.

Figure 5: The bind dialog box

Do the same for the TaskProperties property. Select it, click on the ellipsis, and on the Bind to a new member tab, select Create Field and click OK. The designer should now look like the one in Figure 6.

Figure 6: The designer at this point

Now it's time to implement the code. Double-click the createTask1 activity and add the following code:

createTask1_TaskId1 = Guid.NewGuid();
createTask1_TaskProperties1 = new SPWorkflowTaskProperties();
SPUser user = workflowProperties.OriginatorUser;
createTask1_TaskProperties1.AssignedTo = user.LoginName;
createTask1_TaskProperties1.Title = "Check out the new announcement";
createTask1_TaskProperties1.PercentComplete = (float)0.0;
createTask1_TaskProperties1.DueDate = DateTime.Now.AddDays(1);
createTask1_TaskProperties1.StartDate = DateTime.Now;

The code creates a new task and assigns it to you (the originator of the workflow) and sets some other properties on the task. Set a breakpoint on the first line and press F5. As before, the project is built, packaged, and deployed and its feature are activated. In addition, because I specified the workflow to automatically associate with the Announcements list in the Workflow Wizard, the project system does so and then hooks up the debugger and launches the browser to the Announcements list. In the ribbon, click the Items tab and then New Item. Enter Workflow in Action as the Title and click the Save button. Visual Studio displays the breakpoint line in the debugger, as shown in Figure 7. (If you get an access denied error message in the JavaScript, just click the Continue button.)

Figure 7: The breakpoint line in the debugger

Press F5 to finish debugging the workflow. Go to the task list by selecting Tasks on the left side of the SharePoint page and notice a task has been created.

Project System and Items

You may have noticed a VisualWebPart1 node in Solution Explorer when the project was created, and a Workflow1 node when I added the workflow. These nodes are just folders with special icons that contain the files that make up each SharePoint artifact. If you expand them, you'll see they contain one or more files required to describe and deploy a SharePoint artifact.

To deploy these artifacts to the SharePoint server, they must go into a SharePoint feature and/or package. Features themselves must also be in the package, and when this package is assembled it's called a solution, which is represented by a single CAB file with a .wsp suffix.

There are two nodes in Solution Explorer unique to SharePoint projects, the Features node and the Package node. The Features node can contain any number of sub-nodes, each of which represents a feature that may be included in the Package (which is represented by the Package node).

Visual Studio 2010 includes designers that let you visually manipulate the contents of the features and the package. The Feature Designer, shown in Figure 8, is displayed by double-clicking on the Feature1 node found under the Features node in Solution Explorer. Items in the solution that you can add to the feature are listed in the left-hand panel of the Feature Designer. The right-hand panel lists items currently in this feature. Use the arrows between the panels to add or remove items into the feature.

Figure 8: The Feature Designer

Double-clicking the Package node in Solution Explorer displays the Package Designer, as shown in Figure 9. As they do in the Feature Designer, available items and features display in the left panel, and items already in the package display in the right panel. It's good practice to place features into a package, but some SharePoint artifacts must go directly into a package. Don't worry about this for now, however, because Visual Studio will automatically add new items to an appropriate feature or the package, even creating a new feature if needed.

Figure 9: The Package Designer

Additional Designers and Templates

The Business Data Connectivity (BDC) Designer is another designer in Visual Studio 2010. Business Connectivity Services (BCS) in SharePoint 2010 is an extension of the Business Data Catalog that was available in SharePoint 2007. It's used for integrating data from external systems into SharePoint applications. BCS requires external data to be described in a metadata format, which is imported to the BCS data store and executed by the runtime. The BDC Designer allows you to create such metadata as you would describe an entity data model or a class by using the class designer. Figure 10 shows the BDC Designer. I won't explain here how to build a BDC model. Just know that using the BDC Designer makes the task much easier.

Figure 10: The BDC Designer

You've seen how easy it is to create Visual Web Parts and workflows, and then quickly build, package, deploy, and debug them in SharePoint 2010. There are many other project and item templates that help with developing site definitions, list definitions, content types, event receivers, and more.

Two unique project templates enable you to import existing SharePoint artifacts created in SharePoint Designer. You can export an entire SharePoint site into a SharePoint solution WSP file and then import some or all of the artifacts into Visual Studio 2010. Once imported into Visual Studio, you can modify the artifacts and add additional functionality, then use the project system to build, package, deploy, and debug them. This can also be helpful to get these artifacts under source code control and part of a repeatable process. In addition to importing a WSP file, you can import a reusable workflow that was created in SharePoint Designer. You can use the workflow designer shown earlier to modify the imported workflow's activities, such as adding code (which can't be done in SharePoint Designer) or additional activities.

In addition to the feature and package designers, other tools also make Visual Studio 2010 an effective IDE for SharePoint development. For example, the Packaging Explorer tool window allows you to see all the packages, features, items, and files that make up your solution, and the Server Explorer lets you browse the artifacts in the SharePoint server installed on your development machine.

Advanced Customization Features

The new SharePoint tools in Visual Studio 2010 give developers a high level of configuration and extensibility. When you begin developing SharePoint solutions, the project system automatically builds up features and packages. However, as you become a more knowledgeable SharePoint developer and start building more advanced solutions, you'll likely want to change the default behavior. Fear not—the project system doesn't lock you into the default behavior! You can create your own features and split items between them however you want. You can create your own deployment configurations to control exactly what steps are taken when you deploy your solution, and you can create extensions to the Visual Studio templates and tools by using a robust, built-in extensibility API.

All the Visual Studio features discussed in this article simplify the development of SharePoint 2010 solutions. Visual Studio 2010 provides ASP.NET developers and others with the familiar Visual Studio environment, which includes the integration of source code control and other application lifecycle management features that can also be used to create SharePoint solutions. If you're familiar with Visual Studio, the 2010 release enables you to start developing SharePoint applications using your existing skills. To learn more about the features discussed in this article, or to learn more about Visual Studio 2010 and download the current beta, visit Microsoft's Visual Studio site.