Sunday, 22 August 2010

SharePoint or Asp.Net MVC for building a new and simple web site

I was recently on a project where we were faced with the choice of what platform to base a scoped down prototype web site on. Based on the team competencies and the fact that we had already developed several SharePoint sites for the customer we were basically down to two choices, SharePoint or developing an Asp.Net MVC site from scratch. I consider Asp.Net MVC superior to Asp.Net so a regular Asp.Net WebForms project was out of the question. SharePoint is mainly a collaboration solution best suited for Intranets and portals. Even so, many companies use the platform for their company website because of the growing amount of SharePoint developers and other benefits of the platform such as extensibility.

The purpose of this blog post is to share knowledge for others who might be faced with the same choice of using SharePoint or Asp.Net MVC for a very small web site with few requirements.

About the team
We were 4 developers, a scrum master, a part time interaction designer and a part time graphical designer on the team. None of the team members were SharePoint or Asp.Net MVC specialists. None had any experience worth mentioning on SharePoint 2010. The average experience in years with programming of the team members were less than 10 years. Most had worked with SharePoint for some years but none of the team members had in-depth expert knowledge on all sides of SharePoint development.

A short note about the scope of the project
Time span of the project was about 2 months including planning, design, development and testing. Without going to much into details, here are the features of the site:

  • Integration of some external social media widgets.
  • Very basic publishing of simple content.
  • Branding and fancy visual design.
  • Some commenting, mailing list sign up and feedback features.
The site was a pilot project so we did not have strict requirements on quality assurance etc.

Platform choice
The decision was to use SharePoint as most of the developers were more familiar with SharePoint over Asp.Net MVC. The decision was inline with the company IT-strategy and most of the developers were keen on trying out the new SharePoint 2010.

Experiences
At the time of the project it just happened that I was starting a new hobby project using Asp.Net MVC on my spare time so I had the opportunity to compare SharePoint and Asp.Net MVC development side by side. The two projects were similar in many ways. In the comparison below I only discuss issues that are relevant to both platforms. Many of these problems have also been encountered in previous projects so they might be said to be typical problems you might expect to run into.

Problems we encountered while starting a new SharePoint 2010 project
  • We had to switch to a new development environment and install Windows 7 since SP2010 requires Windows 7. Installing Windows 7, setting up SharePoint and configuring all your nice to have software typically takes two days.
  • We later got licensing problems for the OS and Visual Studio. This is not a big problem but all of these small non-code related things combined make a lot of noise.
  • SP Feature mess: We had trouble setting up page layouts. It kept getting ghosted automatically. We found out that some meta tags attributes on the page layout caused it to automatically getting ghosted during deployment. This resulted in several wasted dev hours.
  • SharePoint has a lot of built in JS such as the init.js file. One of the social media widgets we wanted to use would not run along side the SharePoint JS on IE7. Debugging minified widget code and thousands of SharePoint lines was not anything we wanted to do so we had to write some custom code. Again several hours wasted on debugging and custom development.
  • SharePoint 2010 still renders bad html and lots of other page elements, js and other markup that is not needed for a Internet facing site. The site even tried loading Silverlight when used as an Internet facing site. Chrome crashed because of the Silverlight plugin. This was fixed by adding a SPSecurityTrimmedControl around the ribbonrow.
  • We added several web parts to the web part gallery and we encountered problems that made the add-webpart ribbon unusable since the add button got hidden beneath the ribbon bottom edge on some browsers.
  • We encountered problems with the NoteField. We wanted more than 255 characters for the text. When deciding to use the html rich text field instead we had to change the content type and this is not a walk in the park if you have already created some test pages you would like to keep.
  • Each time a new content type field is added there's often problems for the other developers. The other developers need to upgrade their solution.
  • VS caching bug. While doing deploy from SharePoint within VS we sometimes got this error: deploying Activating feature 'OurFeatureName' ...
  • Error occurred in deployment step 'Activate Features': The field with Id {e3575ee4-1b6e-43fc-b243-77f727f33e16} defined in feature {a36d44c1-b523-4235-950a-59ed763d2588} was found in the current site collection or in a subsite. This error had to do with some state being cached by Visual Studio 2010. In this case we had to restart VS.
  • SharePoint includes a bunch of js and css files. To optimize page rendering on the client we cleaned up and customized the minimal.master masterpage using editmode controls etc.
  • We created XSL for the Content by Query (CBQ) web parts and had to figure out why the CBQ didn't list our pages. Debugging this was time consuming.
  • We also had problems with web parts not being deployed because of inconsistencies between .dwp and .webpart files.
  • Another problem related to web parts not being deployed had to do with mismatch in the SP2010 .spdef files that might be caused by code merging problems.
  • A typical error many do on SharePoint. XSL files packaged incorrectly and end user in anonymous mode don't have access to the xsl.-files and the page breaks.
  • Then we had problem with the server. The system was a small pilot project so the server we got was an old outdated server. SharePoint 2010 simply did not run on the old server without extensive reconfiguration.
  • We copied a SharePoint feature from another project. We forgot to change a GUID and things just did not work. Debugging, again not trivial.
  • SharePoint 2010 does not support IE6 so we had to add a custom warning message for IE6 users. The lack of IE6-support has in retrospective been a problem because it also resulted in down prioritizing IE6 for the front end anonymous view of the site and we have got several complaints from end users who did not understand why the site looked bad on their browser. Also showing of the site is also problematic because the company still used IE6 as the default browser so this lead to embarrassment as we didn't always have control of the installed browser at the location where the web site was presented.
  • The page layout or list we tried to add at some point simply would not be added to SharePoint. No easy way to figure out what was wrong with the xml. The schema.xml for a list is not particularly pretty and inviting to work with. There are of course tools to help you with this but the work all becomes very complex and awkward unless this is the only thing you do for a living.
  • Then, one of us had problems updating the web.config. Updates did not affect the site on the developer’s machine. After an hour wasted work we found out that SharePoint 2010 use a different web.config file. The new web.config file is under the layouts folder in the 14 hive.
  • Next problem; SharePoint redirected mobile devices to a mobile site by default so we had to customize this also.
  • Then we got problems on the Publishing Images doc lib. Some unexpected error occurred when navigating to it. Still don't remember what was done to fix it. Simply too many problems and solutions to keep track of.
  • We had a lot of static html code that were inserted in content editor web parts. Part of this static html was some javascripts used for client side paging and other GUI effects. In SharePoint this had the affect that the JavaScript altered the content of the web part while the user was editing the web part. When saving the web part the user would be saving the jQuery altered version of the html. To fix this we had to link to a separate file instead and update this one rather than editing the web part content itself. With Asp.Net MVC this would be a simple text field with html. The wysiwyg of SharePoint just made things more time consuming here.
  • As with other typical SharePoint projects we had to set up content types, set default page layouts for a page library, what page layouts are available for a site etc. All these things take time to configure in the site definition. This is typically tedious and boring work.

Problems I encountered when starting a new Asp.Net MVC project
  • First problem: You code everything from scratch this can be a frightening enough it self. Using some sample code as a starting point might help a lot.
  • You get 'Object reference not set to an instance of an object' errors and you can't figure out what is wrong. Asp.Net MVC uses a lot of convention over configuration so there's a lot happening under the hood. Debugging this might be difficult because there a lot of abstractions and inner workings that you might not want to dive into.
  • More convention over configuration problems. If you miss a convention or have a convention implemented wrong you will often not get a compile time error message and it’s difficult to locate the error.
  • Figuring out how the routing works on XP with IIS5.1 is difficult. Not very intuitive if you are still on XP.

Conclusion
Asp.Net MVC is simply a web application framework. SharePoint is a software platform for collaboration and web publishing and has a rich set of capabilities out of the box. So basically what you are doing in SharePoint development is to customize the existing features, tweaking features, overriding stuff, extending features or even stripping them way. On Asp.Net MVC, on the other hand, you develop the site basically from scratch. For most developers it will be more interesting and exciting to develop something from scratch that they have full control over, not having to abide by the complexities of SharePoint and having to sit and configure XML files all day long.

If you know that you are going to use some built in feature of SharePoint you should consider SharePoint, but if you are not going to use any of the strong selling points of SharePoint such as document management, workflow, compliance, publishing, document search etc you should definitely build it your self.

Benefits of Asp.Net MVC over SharePoint for small and simple web sites
  • Asp.Net MVC uses convention over configuration. In most cases this makes development very fast as the conventions reduces the work to be done as well as providing a model (MVC) for architecting and for how to arrange code in a consistent and clean manner that further reduce complexity and speeds up development. Faster development means cheaper development and enables early testing which is important for a prototype.
  • You feel more productive as everything you do has a purpose and is directly affecting the solution. Every line of code has direct impact on the actual feature you are working on. SharePoint xml configuration is often used to configure some feature that you don't even need in the solution but you have to configure it anyway just because it's there and available be default to users. A lot of tasks on SharePoint simply seem like a waste of time since you are not working on the required features but instead on removing the features that are not required.
  • Most developers find it more fun to write code than writing XML. When writing code you get to be creative and show how good or smart you are. With XML configurations you have to stick to the schema, no room for creativity.
  • By using Asp.Net MVC we would have Azure as an alternative or backup hosting model.
  • SharePoint development requires a lot of competency. To customize a SharePoint site you need to know web development as well as XSL, the SharePoint object model, feature stapling, site definitions, WSP packaging, SharePoint security model and a bunch of other things. Since very few developers are experts in all of these areas it takes a lot of coordination and teamwork. More dependencies means more development time.
  • A part from the social aspects and skills required there are the complexities of the technical solution it self. In general, SharePoint introduces a lot of complexity that makes development less fast. Lots of different type of code in different places, lots of classes, lots of different configurations on different levels, various tools such as STSADM, lots of scripting commands to remember, many folder locations. Lots of concepts and features. If you want to look into the database to try figure out what SharePoint is doing you'll also meet a wall of complexity there also. More complexity equals developer headache.
Benefits of SharePoint over Asp.Net MVC for small and simple web sites
  • SharePoint has a lot of built in features, some of these might be exactly what you need. For example, Web parts that can be moved between web part zones was one such feature we made use of.
  • As with all IT-projects you must take into consideration future requirements. SharePoint's comprehensive platform might be what you need for your site in the future when your site grows larger and features such as versioning, document management etc may be required.
The big take-away from this blog post
Complexity = more development time.