I was recently asked a few questions from a magazine publisher about my thoughts on SharePoint 2007 development and some of the challenges it brings for developers who are new to the game.  There’s no one right answer to these questions of course (talk to another developer and you’ll probably get different answers), but these were my thoughts so I thought I’d share them.

1. 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 initially.  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. It's rare to meet a developer that knows every feature well. Just when you think you have a good handle on the product you learn something new that you didn't realize was there.

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. When I first started doing SharePoint development I felt comfortable with the C#/VB coding but was confused by the various SharePoint XML files. 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.

2. 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 (and much less code intensive). The SharePoint API offers a large amount of functionality but knowing how to leverage all of it can mean climbing an intimidating learning curve. Taking the time to research different tools and features (3rd party and those built into SharePoint) can also minimize the learning curve significantly, minimize a lot of custom XML document coding and lead to increased productivity.

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.

3. In your opinion, what kind of job is Microsoft doing bridging the gap between SharePoint and developers? Do the VS extensions for SharePoint  sufficiently support SharePoint dev in VS?

Microsoft's definitely catching up with developer tools support although the popularity of free 3rd 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 CTP 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.

4. Are there times when you don't recommend building on top of SharePoint, even if it's already deployed and available? What kinds of scenarios or situations might make what seems like a good SharePoint app opportunity not such a good idea?

SharePoint provides a centralized way to access documents, data and applications. If SharePoint is already deployed it makes a lot of sense to train employees to go to one place for everything they're doing. If SharePoint isn't deployed then I'd need to hear more about the customer's needs. 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.

Developers can certainly build and deploy applications built specifically for SharePoint which can be the appropriate route to take in some situations. Finding qualified SharePoint developers can be challenging and costly in some areas though. By linking standard ASP.NET applications into SharePoint a wealth of developers can be tapped for development and end users still go to a single place to launch applications. There are certainly objections that can be brought up against this approach, but it's a viable solution when the situation is appropriate. I'm a "keep it simple" kind of person. The more complex an application is the more difficult it can be to support and maintain in the future especially when employee turnover and software upgrades are taken into consideration.

For more information about online and video training solutions for .NET, SharePoint or Silverlight please visit http://www.TheWahlinGroup.com.