As I mentioned previously, I’ve had the wonderful opportunity to gain more experience developing a MOSS application for a fantastic client with two other consultants (with the project lead being a SharePoint veteran in our company.) Sadly, my contribution to the project has come to a close as the other two consultants prepare to deploy the finished product; however, I’m grateful for two things:
- Aside from the usual bumps in the road, we were successful in providing our client with what they asked for within the time and budget we were given.
- My experience was enjoyable and successful to a point that I can be even more useful in future MOSS projects. This happens to be critical for our Atlanta office, because now it puts us in a better position to compete for upcoming MOSS projects without having to use resources from other offices to fill them, therefore increasing our utilization as a team.
More than likely, the next project for me will not be a MOSS application, but will instead be “just” an ASP.NET application – which I’m actually looking forward to. But before that time comes and while it’s fresh on my mind, I’d like to share a few more thoughts on what I think others should know about MOSS development:
- Lists, lists, lists. At the beginning of the project, our project lead kept referring to all of these “lists”. I had lists coming out of my ears! In our design, we even had plans for a “list of lists”. As a favor to me, we refrained from calling it a “list of lists” to stop my head from spinning; but it didn’t change the fact that everything in SharePoint is stored in a list – basically a configurable data table. The more you grasp that concept, the better you was able to understand how to create and automate them with our C# code.
- “Out of the box” or custom. If you’re building a custom MOSS application, you’ll need to find out early how much custom development you’ll need versus automating what’s already there for you. When the client starts asking for something to behave just slightly different than how it works “out of the box” (we must have said this phrase about 50 times in the past 6 weeks), you’ll discover the need to create custom webparts and/or a lot of research finding out how to change default behaviors. For example, it took us days just to figure out how to make our column names wrap in an edit form – that was frustrating!
- No “Page_Load” for you. Throw out the regular ASP.NET page events that you’re used to – no good. For example, if you want an action to be triggered by another action (I don’t know, like when the “page loads”!), you have to create a “feature” and code it to be “activated” when the site is created. To this day, we were puzzled to not find a place to put code that would run every time a page was rendered. In our case , this meant that we unable to refresh our left navigation in the event that a new site was created asynchronously; so we had to find several other places to strategically fire this code, leaving holes where the navigation the user sees may not be entirely accurate.
- Getting to know the GAC and “iisreset” better. When you’re building a MOSS application, you’re not building a new application from the ground up; instead, you adding pieces (webparts, features, and other class libraries) to the existing SharePoint application framework. This means that your development environment has to be on a server (we each used a Windows Server 2003 VPC with MOSS and Visual Studio installed on it). Then every time you want to test your stuff, you have to build your DLLs, copy them to the GAC, and reset IIS … every time! And then if you want to debug your code, don’t forget to attach to the “w3wp.exe” process in Visual Studio. It was nerve racking at first, but now I can do it in my sleep (I probably did!)
- SharePoint really is “hot”. Now that I’ve basically given an overview of the quirks and frustrating things about MOSS development, now it’s time to tell you this: SharePoint is really “hot” and for good reason. I'm always amazed at how much we can accomplish in a matter of weeks. The configurable pieces it already has are incredibly useful, and the possibilities of creating custom collaborative solutions to make a company more efficient are endless. Despite several setbacks getting used to MOSS development, I do know that we could not have built this solution we’re about to deploy as quickly, scalable, and lot of other things than if we built it from scratch using just ASP.NET. Sharepoint is well worth the learning curve!