As developers come and go, I find myself with new team members who have ASP.NET experience but no SharePoint experience. My approach to web part development is meant to get them up to speed quickly. The process that I use is
- Build traditional ASP.NET web page in a ASP.NET web application
- Convert the web page to a user control.
- Create a thin web part that loads the user control.
- Deploy the assembly to the GAC, and the control to the 12 hive.
You will notice that this does not look like the MSDN approach. There is no requirement to install VSeWSS, or any other tools. In fact, this approach could be used on a XP development machine because the web part code shouldn’t require a reference to the SharePoint dlls. This makes it easier to setup for a new SharePoint developer.
The real reason I use this approach, is because I like using a visual designer for visual components. Yes, I know "drag & drop" programming isn’t glamorous, but the speed for getting your controls to "look right" is impressive. Those of you in the know will recognize this approach as a statically bound SmartPart. I have built web parts by overriding CreateChildControls(), but that should be for learning purposes only.
This approach also makes deployment easier. The code can be packaged into an assembly containing many web parts and supporting code. We use the wonderful WSPBuilder to build solution packages for deployment. As we are required to debug and upgrade the web part, the code is in an assembly that we can manage normally, and the UI is in the ascx control on the server. This makes it easy to upgrade the web part in place, without requiring changes to the SharePoint sites or pages.