Developing with SharePoint 2010 (part 1) - Platform Development Tools, Development Server Configuration

1. Platform Development Tools

One of the big improvements in SharePoint 2010 is its tooling. In previous versions, platform developers were forced to rely on home-grown or community-supported tools to get any serious development efforts off the ground. Using Visual Studio 2010, developing solutions that target the SharePoint platform is much easier because of a number of new SharePoint-specific integrated development environment (IDE) tools and project templates.

Visual Studio 2010 and SharePoint Designer 2010

In addition to Visual Studio 2010, many improvements have been added to SharePoint Designer 2010. When it comes to doing any design work in SharePoint, SharePoint Designer has always been the way to go. Using the combination of Visual Studio and SharePoint Designer provides practically all the tools that we need to develop SharePoint platform applications.

TypeMock Isolator

Having said that, there are still a few areas that aren’t addressed by the combination of Visual Studio and SharePoint Designer. For example, when it comes to test-driven development, isolating dependencies to test custom SharePoint code can be challenging. Common practice would mandate the use of a mocking framework, but many of the classes in the SharePoint object model are sealed, making them difficult to mock. To address this particular problem, TypeMock Isolator provides a dependency isolation tool that is both integrated with Visual Studio 2010 and able to mock SharePoint sealed classes. In effect, we can write automated unit tests for SharePoint without actually touching the SharePoint platform.

Red Gate .NET Reflector

The sheer complexity of the platform is another area where a third-party product can help, and this issue will be the source of much frustration for any developer building a complex business application on the SharePoint platform. Of course, plenty of documentation is available to help, but there will come a time when a piece of code just doesn’t behave as you expected.

Experienced developers will be aware of .NET Reflector, a tool that is capable of disassembling .NET assemblies to expose their inner workings. When things don’t behave as expected, the only way we can move forward is to disassemble the application binaries and try to work out what’s going on. This works well, but it can be time-consuming and difficult to track what’s going on in disassembled code. To make this process much easier, Red Gate provides the .NET Reflector Pro product. The product runs as an add-in to Visual Studio 2010 and allows developers to debug third-party assemblies. Or in other words, when things don’t go according to plan, we can step in to the SharePoint assemblies and track down exactly where the problem lies in the same ways we use to debug our own code.

Sysinternals DebugView

A lot of the code we write when developing SharePoint applications runs behind the scenes. It can be difficult to connect a debugger to the process in which much of this code runs without causing system instability. Furthermore, when an application is deployed to a farm environment, the problem is compounded by the fact that our code is running in more than one server. A few solutions to this problem are possible. The SharePoint platform provides a Unified Logging Service (ULS) that is intended to be a central source for all tracing and logging information, and this works well when tracing information needs to be included in context with other SharePoint-generated messages. The drawbacks to this approach are the relative complexity of using the ULS logs and the sheer volume of data produced in the logs. In my experience, the easiest way to debug programming errors in a complex application is to make use of Sysinternals DebugView. By simply adding Trace.Write and Debug.Write statements throughout our code, we can view the output at runtime using the DebugVew user interface.

SharePoint 2010 provides a few new tools that make it much easier to troubleshoot performance issues or debug code that runs in a user-initiated process such as a web page.

2. Development Server Configuration

For development purposes, SharePoint 2010 can be installed on either a 64-bit Windows 7 or Windows Vista SP1 client machine or a 64-bit Windows 2008 or Windows 2008 R2 server.

Defining an SPRoot Environment Variable

By performing a standard installation of SharePoint, most of the program files are installed at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\.

Take the following steps:

Using Office Applications in Windows 2008 Server

Because Windows Server 2008 is not deigned to be a client operating system, some of the integration features of products such as Word 2010 don’t work as you would expect. All Office 2010 applications come with a new backstage area that, among other things, allows users to publish documents easily to SharePoint document libraries. For this feature to work correctly on Windows 2008, the Desktop Experience feature must be enabled. To enable the Desktop Experience feature, take the following steps:

Debugging and Unit Testing SharePoint Applications

SharePoint 2010 is a 64-bit application. Therefore, all the code that we write that will run within SharePoint-managed processes must also be 64-bit. This detail can cause a bit of confusion, especially when you’re trying to debug console applications or run automated unit tests.

To illustrate this point, suppose we have the following simple event receiver:

public class DemoEventReceiver : SPItemEventReceiver
    {
       public override void ItemAdding(SPItemEventProperties properties)
       {
         using (SPWeb web = properties.OpenWeb())
         {
           web.Title = "Some New Title";
           web.Update();
         }
       }
    }

We could create the following unit test using TypeMock Isolator:

[TestMethod()]
    public void ItemAddingTest()
    {
      DemoEventReceiver target = new DemoEventReceiver();
      SPItemEventProperties properties = Isolate.Fake.Instance<SPItemEventProperties>();
      using (SPSite site = new SPSite("http://sp2010dev2/"))
      {
        using (SPWeb web = site.RootWeb)
        {
          Isolate.WhenCalled(() => properties.OpenWeb()).WillReturn(web);
          target.ItemAdding(properties);
          Assert.AreEqual(web.Title, "Some New Title");
        }
      }
    }


					  

When running this test within Visual Studio, a System.IO.FileNotFound exception is thrown, suggesting that the web application could not be found.

This error is misleading; if the site URL is correct, most likely the error is being thrown because we’re trying to use the SharePoint object model from within a 32-bit application. Although Visual Studio supports 64-bit code, by default many projects are created in 32-bit mode, particularly console applications, as you’ll see later. Also, the test runner within Visual Studio runs as a 32-bit application, meaning that unit tests cannot connect to SharePoint objects. Although you can force the test runner to use 64-bit, this uses a different test runner that runs as a .NET 4 application; as a consequence, SharePoint is not supported, since it is based on .NET 3.5.

All is not lost, however; when creating unit tests, it’s generally considered good practice to isolate all dependencies, and with clever use of TypeMock, we can change our unit test as follows:

[TestMethod()]
    public void ItemAddingTest()
    {
      DemoEventReceiver target = new DemoEventReceiver();
      SPItemEventProperties properties = Isolate.Fake.Instance<SPItemEventProperties>();
      SPWeb fakeWeb = Isolate.Fake.Instance<SPWeb>();
      Isolate.WhenCalled(() => properties.OpenWeb()).WillReturn(fakeWeb);
      target.ItemAdding(properties);
      Assert.AreEqual(fakeWeb.Title, "Some New Title");
      Isolate.Verify.WasCalledWithAnyArguments(() => fakeWeb.Update());
    }


					  

This time, the test passes as expected, because even though our code is being fully tested, since we’re using mocked SharePoint objects rather than real objects, the test runner can execute our test in 32-bit mode.