Understanding the SharePoint, ASP.NET Relationship

SharePoint is a fairly well behaved ASP.NET 2.0 application.

Most ASP.NET developers run Windows XP and use the built in IIS to develop their applications. That's the model that most developers are used to. However, SharePoint can't be debugged remotely so that means developing on a Windows 2003 or Windows 2003 R2 server. Of course, most people don't want to run Windows Server 2003 directly on their desktop or laptop. That means virtualizing the server with either VMWare, or Virtual PC 2007 - which is free. This in turn means more memory than most development machines have. You'll need at least a gigabyte of RAM to develop with MOSS and at least 768 megabytes to develop with WSS. Add Windows XP overhead to that and you're effectively looking at an absolute minimum of 1GB to do SharePoint development with 2GB being more realistic, and 3GB or more being ideal. Not exactly your standard configuration.

To develop in ASP.NET you basically install Visual Studio and you're done. Everything is in there. Your operating system already has IIS and even if it doesn't you can use the built in CASINI. Unfortunately, nothing comes out of the box with SharePoint -- not even SharePoint itself. If you want to develop on WSS you'll need to install WSS. That requires at least two downloads -- .NET 3.0 and WSS.


Getting started developing gets harder after you install Visual Studio. You also need to install three additional pieces: Visual Studio Extensions for Windows Workflow Foundation (VSeWF), Visual Studio Extensions for Windows SharePoint Services (VSeWSS), and the Windows SharePoint Services Software Development Kit (WSS SDK). The VSeWF adds the workflow capabilities to Visual Studio. VSeWSS adds some templates (including web parts and list definitions) and solutions generators. The WSS SDK adds some SharePoint specific workflow templates -- in addition to the documentation.

When developing a solution we're used to developing with the support of the visual design surface as in Visual Studio 2005. We get to see what we're developing visually without running the code. Whether writing an ASPX page or an ASCX control you work quicker because you can instantly see the results of your work and because you're working with a tool that supports the design experience.


With Web parts -- and almost everything else in SharePoint -- you're going to have to do it by hand, without the support of a visual design surface. That means more time to do relatively simple things. The ability to add controls to the control tree is something every ASP.NET developer should know how to do, but it isn't something that every developer should do every day.