Getting Directions for SharePoint

.NET developers face adjustments as they start coding for Microsoft's high-flying workflow and collaboration platform.

• By Michael Desmond
• March 6, 2009

Behind the activity is the wildfire growth of Microsoft's file sharing, collaboration and portal platform, which includes Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services (WSS) 3.0 integrated into Windows Server. Last year, the SharePoint business unit surpassed 100 million licenses and $1 billion in total revenue, according to Microsoft. Now organizations are looking to leverage those investments by adding custom functionality and applications to their SharePoint infrastructure.

That trend is producing its share of growing pains, as .NET dev shops contend with SharePoint's unique demands and uneven tooling. At Microsoft's Tech·Ed Conference in June 2008, Chairman Bill Gates admitted during his keynote Q&A that the company had been caught flat-footed by the amount of development activity around SharePoint. At the time, he said Microsoft was working to make SharePoint developers first-class citizens.

Since then, Microsoft has released the free Visual Studio 2008 extensions for SharePoint, which provides Visual Studio project templates for building, debugging and deploying SharePoint projects and applications. The January community technology preview (CTP) of Visual Studio 2008 Extensions for Windows SharePoint Services 1.3 adds 64-bit support, refactoring support for renaming Web parts, and a command-line interface for enabling continuous integration and build. The final version is likely due in April, says Paul Andrew, Microsoft technical product manager for the SharePoint Developer Platform.

"Microsoft has been scaling up our guidance, and our application and tools, really, really fast," Andrew says, noting that Visual Studio 2010 will fully integrate SharePoint development support.

Making the Transition
Evidence of the effort to scale up guidance is evident in Web sites like Microsoft's SharePoint Developer portal and the MSDN-hosted SharePoint Server and Windows SharePoint Services Developer Centers. The sites offer step-by-step tutorials, design patterns, best practices and other resources for developers working with the platform.

Still, challenges remain. Veteran SharePoint developers complain that a lot of critical insight and guidance remains scattered among dozens of individual blogs and SharePoint-themed sites.

"My Google reader is filled with stuff I need to check on, but it's all scattershot," says Rutherford Wilson, director of product management for Atalasoft Inc., an ISV that in February released Vizit SP, an image-viewing application for MOSS and WSS environments. "There are books, blogs, and that's about it."

Ryan Thomas, director of the SharePoint practice at consultancy Syrinx Consulting Corp., says developers new to SharePoint are best served by simply wading into the environment.

"The first thing I would do is build a Web part. Build and have 'Hello World' working in 30 minutes. Then download the SDK and the object model. If you're going to be a developer, understand the object model and learn how to write code," he says.

Thomas advises developers to visit the Microsoft CodePlex site to examine open source SharePoint projects similar to their own.

He warns that seasoned .NET developers may find the dynamics around SharePoint development to be quite different from traditional .NET development. He says SharePoint projects tend to be client-facing, involving frequent and intense interaction with business stakeholders. There's a good deal of expectation setting that must be addressed, in part because these users are often familiar enough with SharePoint to expect quick results.

"VPs, CIOs, business people -- they just don't understand the concept of, 'three weeks and come back with code,'" Thomas says. "It's very important to talk to them."

Tale of the Tools
One of the enduring complaints about SharePoint development has centered around tooling. That situation is now changing, thanks in large part to the release of the Visual Studio extensions for SharePoint and useful utilities like the SPDisposeCheck tool for releasing unused memory. Still, major gaps remain in the SharePoint developer chain.

"The extensions are weak, in my opinion," writes Spencer Harbar, a U.K.-based independent SharePoint developer and frequent speaker at Microsoft conferences, in an e-mail interview. "At best the extensions are a Band-Aid to bridge the gap between where we are now, and the future of SharePoint dev tools."

Harbar says the extensions fall short for enterprise development, which can expose weaknesses and flaws in the tooling. He adds that the integrated SharePoint tooling in Visual Studio 2010 (VS10) should be much better. "I cannot speak much to the VS10 tools without breaking NDAs, but I have complete confidence that they will offer a huge step change in terms of developer tools for SharePoint," he says.

Another issue is the fact that SharePoint environments must run on Windows Server -- a nagging issue for developers who prefer to code on their Windows XP or Vista workstations. Microsoft's Andrew says developers today have two choices: Either run Visual Studio on the same Windows Server OS that hosts SharePoint, or stand up a virtual machine that incorporates Windows Server and the target SharePoint environment. Most shops, he says, opt for the latter solution.

Leading component maker ComponentOne LLC is among them. The company in January released CTP versions of its SharePoint Web Parts line, which include map, chart and datagrid controls for SharePoint environments.

"You need to make sure you have access to a testing environment that is not your development machines, that's particularly important for SharePoint," says Dan Beall, product manager for ComponentOne. "Sometimes you have to use remote debugging. It's not as fluid as debugging on a target machine, but one thing you can do is you can have your code write entries to SharePoint log files. There are a couple of freeware tools for looking at what's in the log files."

SharePoint developers have come to rely on a growing collection of freely available tools and utilities to help them address the extended tool chain. Microsoft utilities, like the SPDisposeCheck tool, help stamp out troubling memory leakage conditions that can occur with unmanaged component code, while the CAML Query Builder eases the learning curve around SharePoint's Collaborative Application Markup Language (CAML). The result: Many dev shops have assembled ad hoc tool chains to address the unique demands of SharePoint coding. (See "The SharePoint Toolbox.")

'The SharePoint Way'
Ultimately, .NET developers face a subtle challenge in adjusting to life with SharePoint. .NET and ASP.NET developers working with SharePoint must be ready to do things "the SharePoint way," says Anne Thomas Manes, vice president and research director at Burton Group.

"SharePoint presupposes a bunch of design patterns and you kind of have to build your application around those design patterns," she says. "And if you want your own design pattern, it's probably not worth the time and effort. Don't attempt to force fit other design patterns into it, because it will just be a very frustrating experience."

Andrew draws a parallel with ASP.NET programming projects, where developers typically start off by building a framework to address administration, security, data access and other issues. SharePoint, he says, essentially acts as the framework.

"That has the advantage that if you take a SharePoint developer, they already know that framework, they don't have to learn a new framework," he says.

The problem is that the SharePoint framework is so large that developers often create custom code for features that are already there. Harbar urges developers to look carefully before concluding that a custom Web part or application is necessary.

"Easily the most common mistake is not having a core understanding of the product architecture and therefore choosing the wrong approach to meet specific business requirements. SharePoint is such a huge platform that it's incredibly easy to start implementing custom code for a task that SharePoint does," Harbar writes.

He adds that developers often make the mistake of assuming that SharePoint is "just .NET," when in fact .NET developers face a significant ramp in mastering SharePoint dev projects.

Even within the SharePoint family there are choices to be made. Manes says that many enterprises today opt to develop for SharePoint Server, when they could achieve similar results and enjoy a more manageable environment by deploying logic to

Windows SharePoint Services (WSS) instead. She says organizations often conclude -- wrongly -- that WSS lacks the features they need to support workflow, coordination, scheduling and other common business processes.

"There are a lot of features in WSS that Microsoft doesn't really advertise to the rest of the world," Manes says. "I can use a Java portlet and have that be the interface into WSS, because that works through the Web services interface as opposed to the .NET interface."

Ultimately, Microsoft's Andrew says that .NET developers must learn to unlearn some of their old assumptions when moving to SharePoint.

"One of issues is people taking the approach -- and this happens because projects need to be done fast -- that their .NET experience will get them through their SharePoint project," Andrew says. "They do have to learn new skills."