SharePoint is a good development platform for applications*

In this article, I clarify that not all apps should be built on SharePoint. I address complaints about source control and SDL in SharePoint.

By Last Updated: September 24, 2007 5 minutes read

Before I get flamed here like I did on another recent crappy post I commented on numerous times, I am not saying all your apps should be built on SharePoint… not in any shape or form.

The comments of that post, while they have some merit, most of them consist of rants and flames by the ill-informed or .NET naysayers. Many complained that you can’t do source control or any real SDL in your SharePoint environment. That couldn’t be any further from the truth. Sure, most people see the only way to create a list, site column or content type is through the browser… others think the only way to create master pages, page layouts or customize pages is with SharePoint Designer. Did you know you could do all of this with files based on the file system? If it is on the file system, then it integrates nicely with any SCM… even non-TFS solutions. All of my SharePoint development work lives in SubVersion… and yes, if you’re wondering, it’s all configured with automated testing thanks to MbUnit. This is all possible… and it isn’t hard. See this post to see a brief discussion on how to do this. Better yet, how do you think Microsoft built SharePoint? I don’t know of another product or framework, including ASP.NET, where you have been given so many code samples on a default install! Just take a look in the SharePoint “12” system folder… there are a ton of samples that have helped me infinitely over the last two years!

What most people fail to realize is that SharePoint development *IS* ASP.NET development at the core. Everything you do in ASP.NET sites can be done in SharePoint. I can hear the .NET naysayers already. Let’s take two common things I frequently hear:

  • You can’t do code-behind files in SharePoint. Yes you most certainly can… How do you do it in an ASP.NET application? You right-click the designer and say “View Code”. But what is really going on here? Visual Studio is creating the code behind file, creating a class within it that inherits from System.Web.UI.Page and adds an Inherits attribute to the Page directive in the page. Guess what? You can do the exact same thing in SharePoint… you just have to do it manually. Yes, that sucks, but that’s the development experience… not the platform.
  • You can’t debug code in SharePoint. Why… because I can’t hit F5 in Vista? Again, what does F5 do for you in Visual Studio on an ASP.NET application? It builds the project, fires the process off and attaches the debugger. You can do that too! Select Debug -> Attach To Process in Visual Studio and select the process (w3wp.exe) hosting the application pool that runs your SharePoint site hosting the code you want to debug. Then you’re ready go to… easy-peasy.

Joel Oleson’s recent post tackles it from a different perspective. I like that he takes the approach on leveraging existing functionality that is provided (*and supported by MSFT… which can’t be discounted) OOTB in SharePoint. I fully agree. When I see a custom app, I say “hey, need search? I have it OOTB in SharePoint. Need a security model? Same thing… OOTB in SharePoint. Plugin model? Ah, Features! Workflow & Web Parts? Nice… all the plumbing is provided by SharePoint.” I see tons of things every application needs that SharePoint provides OOTB. There will always be those developers who want to build everything from scratch… and I used to be one of those. But seriously… who cares? Your client / manager sure as heck doesn’t. They want to see you deliver… plain and simple.

So where does does this whole “good dev platform” fall down? IMHO it is the development EXPERIENCE, not the PLATFORM. Why isn’t there true integration with Visual Studio 2005 like there is with SharePoint Designer? There should be. Why can’t we get a “Pro” version we can install on Windows XP Pro / Vista? Right now, it is all about resources that MSFT allocates to the task.

Let me be very clear… I’m not saying SharePoint should be considered for every single application. But to simply say it is generally a bad platform shows how little you know about the product or that you haven’t done your research to make wildly incorrect statements like SharePoint doesn’t work with source control. Just because you haven’t figured it out doesn’t mean you CAN’T do it.

I know this is going to rub some people the wrong way. My point here isn’t to generate a battle or slam anyone in particular (ok, maybe a slight to a certain blogger ;)). My point is to help you open your eyes a bit more than they are with the product. I hope this helps a bit with that.

So why do I call Palermo’s post “crappy?” Because it is an incredibly irresponsible statement with absolutely no follow through. If I didn’t know better, I’d say it was an attention getter (is it? looks like a duck, smells like a duck…). There was more participation in the comments by certain individuals than there was by the post’s author. He simply tosses SharePoint out as a good dev platform because he can’t install it on Vista. That’s like me saying “Vista sucks because I can’t install the software to customize my universal remote”. Please… how about taking a few more minutes to not only evaluate the product, but if you don’t understand something, feel free to ask! There are plenty of forums, both as web forums and newsgroups… all free solutions! Don’t make some profound statement for something you don’t understand. That post was nothing more than dropping a stink bomb in an elevator at the 23rd floor and getting out while it was on it’s way down.
Branded horizontal divider.