(Version 2.0 - October 10th, 2009)

In this series, I'm going to compare the functionality of SharePoint and Sitecore from a developer perspective in each area and both candidates can collect "points" from 0 (has nothing to contribute) to 10 (great integration and functionality).

This series will cover the following areas:
- Introduction (Part 1)
- Installation and General Architecture (Part 2)
- Configuration (Part 3)
- Customization and Designer Experience (Part 4)
- Integration with Developer Tools (Part 5)
- Feature Deployment (Part 6)
- API und Data Model (Part 7)
- Integration with other systems (Part 8)
- Conclusion (Part 9)

Integration with Developer Tools

In the last part of this series I examined features and tools both framework offer in terms of customization and web designer support. This part of the series is diving deeper into the world of web development with SharePoint and Sitecore.

One of the main reason for an organization to invest in enterprise-class Content Management Systems is to build extended functionality on top of those frameworks. At netzkern we have several customers that made significant investments into their IT infrastructure to enable enterprise application and business process integration, especially using open standards like XML (SOAP, REST, POX). Because of that, extensibility and integration are critical parts of Content Management Systems today and both SharePoint and Sitecore have various integration features and extension points. The question is, however: How easy is it to use those features and interfaces as developer to plug in my own code? Do I need to change the way I'm used to work? And how does the system support me?

As SharePoint comes as part of Microsoft's server family, the tool to develop SharePoint functionality is of course Visual Studio. So, how do we get started? Well, as developer with some experience in the Microsoft space, you might expect the following procedure: Install SharePoint, install Visual Studio, download the appropriate SDK (in this case called "Visual Studio 2008 Extensions for Windows SharePoint Services, Version 1.3", or just VSeWSS for short), take a short look at some API samples, create or open an appropriate sample file, write three lines of code, hit "F5" and see your first shiny "Hello World". And since we're talking about version 1.3 of VSeWSS, that's finally the way it works.

While getting started with VSeWSS is pretty straight forward by now, manually deploying custom SharePoint solutions is surprisingly complex. But before we talk about that, there is one important thing to mention regarding SharePoint development in general. That is, to install either MOSS2007 or WSS 3.0, you need a Windows Server operating system. Although it is possible to use special third party tools to install WSS 3.0 on Windows Vista (see Bamboo Solutions), this way is not supported by Microsoft and may cause problems during development or after deployment to a "real" SharePoint installation. As developer you usually choose one of the following solutions: Install Windows Server on your workstation, use a virtual machine (VMware, Virtual PC, etc.) with Windows Server or use a central Windows Server with Remote Desktop for development. Although you can use Visual Studio on your WinXP for local development, you need to deploy your code on a server machine for execution and remote debugging (which, by the way, is not that straightforward in most scenarios).
The most important feature that VSeWSS brings to the table is finally the ability to hit F5 in your Visual Studio and see the results of your work right away. This alone is a huge advancement when compared to the way SharePoint development used to be. There are a lot of things, VSeWSS takes care of in the background. Let's take look at what happens:
As I briefly described earlier, the way to add functionality to SharePoint is by developing so called Features. Features can be deployed manually by copying all necessary files into the "12 hive" folder and executing a few commands on the command line -or- by using a so called Solution Package (a "WSP"). A Solution Package is basically a .CAB-File (Microsoft's ZIP format) with a specialized internal file structure, additional configuration files and a .WSP extension. Back in the old days you had to create that .CAB file by yourself, but today VSeWSS creates it for you and even allows you to inspect and change its contents live in Visual Studio. If you wanted to create the .CAB file manually (which you don't need to anymore), the first thing to do would be to create a DDF configuration file for the MakeCAB.exe command which would be used to create the .CAB archive (and later be renamed to .WSP). Then you would have to create the Solution Manifest (named manifest.xml), which contains information about all contents of the .WSP and directives about how to deploy the contained Features to a SharePoint farm. A Solution Package can contain several Features in separate folders and each of those Features needs to have a Feature Definition file (named feature.xml) and optionally additional files (Elements files for lists and list items, resource files, etc.).
But that's not the only thing, VSeWSS manages for you. It also takes care of adding your compiled code all additional resource files to the Solution Package, extends the configuration files appropriately, deploys and installs the package in your SharePoint farm and activates the Feature so that you can get your results very fast. In case you would like to know more about what happens under the covers (and you should, if you want to be a real SharePoint developer), I recommend reading the following articles on MSDN (part 01, part 02) and to take a look at the WROX SharePoint Box, which I highly recommend.
While it has been quite painful and complex to deploy custom code using the Solution Framework, VSeWSS makes it significantly easier and developing SharePoint solutions is actually fun again. All steps can also be automated and integrated with various software configuration management and build tools.

Advantages

1. SharePoint provides a Visual Studio extensions that helps the user significantly by providing Visual Studio templates and automating the complete packaging and deployment process. This makes it easy for developers to get started as long as everything goes well.
   
2. SharePoint provides a full-features deployment system called the Solution Framework that developers can use to deploy their code within a SharePoint farm. We will cover that in more detail in the next part of the series.
   

Drawbacks

1. Deploying custom SharePoint solutions is still very complex under the covers. All artifacts need to be described using various XML files and packaged using specialized tools, as well as deployed, installed and activated in the target environment, which would mean to use a combination of console tools and the SharePoint Administration in addition to creating the .WSP file and all its contents manually. Fortunately, that complexity is largely hidden from the developer, but if something goes wrong, finding the source of the problem requires some time.
   
2. SharePoint cannot be developed completely on a usual WinXP or Vista workstation because it is at least necessary to use Windows Server with an installed SharePoint as runtime environment (or to use unsupported third party software). To have a reasonable development lifecycle, using Windows Server as development platform (be it native, in a virtual environment or on a central server) is strongly recommended.

As you know, Sitecore is based on .NET, and so the tool to develop extended Sitecore functionality is of course Visual Studio as well. So, let's see how to get started here... Again, as developer your expectation might be the following: Install Sitecore and VS2008, download the SDK, take a short look at some API sample, create or open an appropriate sample file, write three lines of code, hit "F5" and see your first shiny "Hello World". And guess what? That's exactly the way it works - and it strong contrast to SharePoint, that's all there is to it.

From the perspective of .NET, Sitecore is just a well integrated ASP.NET web application with advanced functionality and you can even run it using the WebDev.exe development server that is coming with Visual Studio, regardless whether you're running WinXP, Vista, Windows 7 or Windows Server (2003 and 2008 are supported). You can also use the local IIS coming with those operating systems (yes, even IIS 5.1 in WinXP), it is totally up to you.
This means you get all the things you're familiar with: Debugging .NET code (and even XSLT code) without any additional tasks, deploying additional assemblies to the /bin folder, using source code management tools and experience no limitations while doing your job. The integration of Sitecore and ASP.NET is really seamless. Another great thing is that you're not limited to Visual Studio, but you can even use Microsoft Expression Web to run Sitecore and choose every external editor (e.g. for editing your XSLT files) to change Sitecore solution and resource files.

In contrast to SharePoint, Sitecore provides you with a couple of additional developer tools within the system that can dramatically improve the quality of your results and your personal productivity. By using the integrated debugger tool to debug your web pages, you get a lot of useful information about your code, your renderings and your design, right where you need it. You can also use the Sitecore Developer Center to edit your XSLT code, your layouts and even your .NET code, so you don't need to use Visual Studio for very simple task like a short bugfix or minor update. Sitecore's Package mechanism makes it ease for you to deploy the code you created in your local or central development environment to integration, test and production environments (more about that in the next part of the series) and you can use the integrated log4net to trace the flow of your application without configuring and maintaining a separate logging framework or the Windows EventLog. While creating a reusable content type usually involves a lot of XML hacking, deploying, installing, activating and configuring within SharePoint, using the Template Manager in Sitecore to create your own information structures is a breeze.

Advantages

1. Sitecore behaves like an usual .NET application during development and deployment. Developing for Sitecore is exactly like developing with any other .NET library, as it is fully integrated with Visual Studio and the WebDev server. You can even use the free editions of Visual Studio or Expression Web - or any other tool you prefer as long as it runs on the Windows platform.
2. Sitecore offers additional developer tools as part of the distribution and in form of additional tools through the Sitecore Developer Network.
3. Visual Studio is your one-stop place for developing Sitecore features, there is no need to switch to any other application, except you want to.

Drawbacks

1. For the time being it is not possible to rollback Sitecore package installations. This would be a very, very nice feature for the future, although I'm aware of the complexity of that request.

So let's draw our conclusion here. Developing Sitecore and SharePoint is not that different anymore thanks to VSeWSS, although there are still some minor drawbacks in Microsoft's web content and collaboration platform. Of course, no framework is ever complete nor perfect, but Sitecore has managed to create a great developer experience and a pretty great framework.

Sitecore: +10 points = 34 points total
SharePoint: +8 points = 25 points total

See you soon for part six...

I just relaunched my website at http://www.juliusganns.com. My blog posts will be published in this blog as well as in on my new website. Tell me what you think...

I guess, I own a couple of computers. At the time of this writing I have a Windows Vista Notebook for developing software (Dell Latitude E6500), a TabletPC for designing software, training and consulting (ThinkPad X61), a Netbook for the agile manager (Samsung NC10), a Media Center (Sony VAIO), three XP Desktops for gaming with my friends and surfing at home, a Windows Server 2008, a MacBook Air and a Mac Mini.

As I want to have all my files with me all the time, a sync software is mandatory for me. In the past I used AllSync with a central fileshare via VPN on my server, FolderShare (which is now Windows Live Sync, see http://sync.live.com), Microsoft Office Groove and BeInSync (http://www.beinsync.com/). A couple of months ago I moved to Dropbox (http://www.getdropbox.com). For the moment, it is just working fine, I really love the versioning support and that it runs on both Windows and Mac, but there are some drawbacks. First of all, I cannot choose multiple specific folders to sync between my systems, there is just the one "My Dropbox" folder. Second, I cannot limit certain folders to certain systems - bad for large stuff like music and pictures that I don't need on any system. Last but not least, I cannot choose an existing folder after I have reinstalled my OS that already contains most of the synced data, so I have to choose an empty one and wait until Dropbox has downloaded everything to my newly installed system.

As .NET developer and Microsoft guy, Live Mesh (http://www.mesh.com) seems to be the ultimate tool for the future, although it is still in Beta. Except for lack of version support in the current release, it seems to bring everything to the table that I need (including Mac support) - and it is more than just another online file sync service. As you can read for yourself in one of my previous posts, Live Mesh is a whole sync eco system that can transparently manage all kinds of data, including the one you need in your own applications.

I will also try out Syncplicity (http://syncplicity.com/), just to make sure that I don't miss anything. :-)