Q&A: Dan Wahlin: Grappling with SharePoint
Dan Wahlin is a regular contributor to VisualStudioMagazine.com, where he authors the Wahlin on .NET column. He is also founder of The Wahlin Group, which provides training and services for.NET and SharePoint developers. We spoke with Wahlin about the challenges newly minted SharePoint developers face and how they can work around them.
What is the most difficult thing for .NET developers to grapple with when entering the SharePoint development space?
The sheer magnitude of the product is difficult for developers to grasp. A lot of developers I've encountered consider SharePoint to only be an intranet portal or meeting/document collaboration tool when in reality it's much more than that. It's quite difficult to master everything within SharePoint, which is why some developers are good at Features, others at creating WebPart classes, while others know the Business Data Catalog inside and out.
If I had to pick one SharePoint item that trips up .NET developers it would be the creation, packaging and deployment of Features and solutions, since the files involved aren't used at all when building standard .NET applications and feel foreign at first. Without good tools it can be challenging and quite unproductive to create Features and solutions and deploy them to SharePoint sites. Fortunately, several different tools are available on CodePlex.com and from Microsoft.
What are some common mistakes or oversights that developers new to SharePoint tend to make?
I don't know if there's one main mistake or oversight I can identify, but I've seen things built that could've been simplified quite a bit had the developer taken the time to see what SharePoint had to offer as far as built-in features. For example, event receivers can be created and deployed fairly easily and can be more appropriate than custom workflows in some cases.
Another area that is challenging for .NET developers is the CAS configuration required when doing things like BIN deployment of WebParts. With ASP.NET you drop an assembly in the BIN folder and you're good to go in the majority of scenarios. With SharePoint it's more involved and requires at least a basic knowledge of how partial trust settings work.
SharePoint got way in front of Microsoft as a dev platform. In your opinion, what kind of job is Microsoft doing bridging that gap?
Microsoft's definitely catching up with developer-tools support, although the popularity of free third-party tools out there gives a good indication that they still have a ways to go. The Visual Studio 2008 extensions for SharePoint make it a lot easier to work with things like Features, Lists, WebParts and Site Definitions, and significantly reduce the amount of custom XML coding that's required.
The latest release adds a lot of nice deployment features to simplify building, packaging and deploying a solution to SharePoint and even integrates with environments that are using continuous integration processes. The extensions also run on 64-bit systems, which is great for developers working on machines with a lot of RAM available. The current release provides a nice solution until Visual Studio 2010 comes out, which will provide developers with much more direct access to SharePoint functionality from within the IDE.
Are there times when you don't recommend building on top of SharePoint, even if it's already deployed and available?
From a development and maintenance standpoint, I think it can be easier in some situations to integrate new or existing ASP.NET applications into SharePoint by simply providing a gateway into the application using something like the PageViewerWebPart or even a direct link. Security and other aspects of the application have to be thought through and taken into consideration when going this route, but it offers a "loosely coupled" option.
It really depends on how much direct interaction the custom application needs with SharePoint, such as querying lists, the ability to search application data in SharePoint, access to the SPContext object, the authentication scheme, etc. It also depends on the amount of data to be retrieved and stored and whether or not using SharePoint's Web service functionality is an option.