Good "SharePoint Development" = Good .NET Development
Gregory MacBeth provides a nice enumeration of the skills you need to be a “SharePoint developer”. It’s a good list. I endorse it. But examine it closely, and I hope you’ll come to the conclusion that the way to be successful when building Web site solutions (collaborative or otherwise) with WSS and/or portal solutions with SPS is to be a good .NET developer.
What’s on Gregory’s list? The .NET framework. C# and/or VB.NET. Web services. ADO.NET. XML/XSLT. Windows/IIS security appear before we ever get to anything about WSS or SPS. SQL Server as well (but I’m hoping that you’re spending very little if any time programming directly against SQL Server in WSS/SPS-land).
This is by design. I’ve been building collaborative or knowledge management-focused apps for a long time, and it’s always been frustrating to have operated with tools and platforms several generations behind that which was available for other kinds of solutions. In 2003, WSS and SPS made collaboration and infoworker-focused developers full citizens in .NET Nation. What’s more, it meant that .NET developers could use their skills on collaboration and portal solutions.
What’s truly unique to WSS-based development? For starters:
- Site definitions
- Our object models
- Our Web services (and WebDAV, and FPRPCs)
- List definitions and CAML
Other than CAML, we’re not talking about a special set of tools. We’re just talking about a special set of server facilities. Web Parts aren’t that different from standard ASP.NET custom (a.k.a. server) controls, and besides, when we all unify around ASP.NET 2.0, they won’t be WSS-specific any longer.
When it comes to SPS, the only thing that’s different is creating search extensions, i.e., protocol handlers and iFilters, which are decidedly non .NET development topics.
Which reminds me: Attention tool builders and other interested developers — in the next release, protocol handler development and IFilter development will still need to be in C++. Do not wait for the rules to change, because they won’t (at least not before “v4”). If you want to extend our search technology to new content sources and formats, you might as well get started now. Search gets a lot better in many ways, but the method for developing IFilters/protocol handlers isn’t one of them.
At this stage of the game I can get away with telling you some of the things that aren’t going to change so you don’t dismiss investing in skills/facilities that will still be important for several years to come. Within the next few months, as soon as we start publicly talking about the next releases of WSS and everything in the Microsoft Office System, I’ll start spilling what we are doing next for developers. And in the meantime, I’ll push the envelope as much as I can.
