Radi Atanassov

SharePoint MCM, MVP, MCT and owner of OneBit Software

Architecting your SharePoint application–things you shouldn’t miss out on

So a few people recommended I post my slides or content from my European SharePoint Conference session. I cover a list of considerations that makes a good reference for people undertaking the design of custom applications on SharePoint.

Usually in projects you would have people responsible for the design of the infrastructure and then a development team would dig into the technical design of the SharePoint application. They will try to answer how different components will be used to satisfy the requirements. Solution Architects explore various options for meeting each requirement and all these options and choices intertwine into a proposed design, maybe a model or a proof of concept, and hopefully a document. Projects that miss this communication are either chaotic, or extremely agile.

When doing architecture there is usually more than one possible way to achieve the same thing – the “right” one will depend on the situation and each of the things I’m pointing out here could be equally right or wrong. This is especially true for SharePoint. That is why “awareness” and the knowledge of SharePoint are one of the key requirements for an architect to be any good.

This list is not the ultimate list – it is just my summary of what always lands on my table. It is also not the base for a definitive Technical Design document (it’s a start!). Some items below didn’t get mentioned in my talk as time was limiting what I could include.

Front-end Planning

Page Model – How you plan to store you (ASPX) pages

  • Application Pages (_layouts)
  • ASPX files served from a Document Library
  • ASPX files in folders
  • Publishing Infrastructure – page layouts
  • Consider Web Part Pages vs. Wiki Pages

Form Strategy – Consider how you will capture data and what controls/interfaces you will use

  • Understand how SharePoint forms work and consider using SharePoint’s API’s
  • SharePoint InputControls are great but may be difficult to use and may have limitations
  • Consider exchanging data between forms. Plan Session and ViewState requirements
  • SharePoint Scenario Framework
  • Consider validation requirements and the UX on the validaiton
  • Also consider Silverlight and InfoPath forms as alternatives for capturing data

Client-Side Scripting – plan out any requirements for client-side JavaScript

  • If using validation, plan out your client-side scripting and the use of any frameworks
  • Will you use the Dialog Framework or any other popup/dialog framework/toolkit?
  • Consider the use of jQuery, Modernizr, Knockout

Page Components – define what controls, web parts or other components you will use to create the actual interfaces

  • Web Parts vs. User Controls
  • SharePoint Rendering Templates and the Form UI (_controltemplates)
  • Consider the styling/branding of your custom interfaces – you don’t want your developers to be designers (unless they really are)
  • Iframe – various solutions use Iframes to display external content or components hosted elsewhere (plan out authentication)
  • Consume HTML asynchronously – I have seen solutions that grab HTML from an ASHX or other services
  • InfoPath – always think about the User Experience when you deal with InfoPath

Resource Files – evaluate how you will use resource files and what components will require localisation

  • Code-behind resource files
  • ASPX resource files (14\Resources, AppGlobalResources)
  • Feature Resources
  • Localised Web Templates

Back-end Planning

SharePoint Data Model – define the storage of data


  • How are you going to store data?
  • How will it scale?
  • How are you going to access it? (SP OM, External Data (BCS), Web Service calls)
  • How are you going to “replicate” it? (backup, archive, move/copy, log)
  • How are you going to store applicaiton settings (SP list, P&P Settings)

Visual Studio Solution Structure – How will you structure code and artefacts

  • Number of WSPs/Number of Features
  • Separation of code
  • Separation of SharePoint items
  • Namespaces and naming conventions
  • Source Control strategy

Design Patterns/Anti-Patterns – make your code maintainable and nice if it makes sense to do so

  • SharePoint Service Locator (P&P)
  • Façade/Adapter
  • Consider/plan your data access layer

Security Model – don’t think about it in production


  • Kerberos/NTLM (consider the requirement for Kerberos)
  • Claims (consider the effort to pull it off and any side-effects)
  • Plan the use of service accounts and access for/to external systems


  • Use SP groups or AD groups?
  • Nested groups
  • Do you really need item-level security?

Exception Handling and Logging – define how to display/capture errors and how you log them

  • Consider how you will display errors to the user (don’t do lblMessage.Text = ex.ToString(); )
  • Define what needs to be logged and how
  • SharePoint Logger (P&P) gives you a good API for Diagnostic categories and areas


Solution Deployment Frameworks – define how your developers will deploy

  • MSBuild
  • NAnt
  • 100% PowerShell
  • CKS-Dev addin  for Visual Studio 2010

Other Knobs and Dials – there are many other things that affect deployment

  • WSP lifecycle
  • Feature activation
  • Activate on Default
  • Deployment configuration
  • WSP additional DLL's
  • Force on Activate
  • Safe Controls
  • Web.config modifications
  • Web Part deployment
  • List re-creation
  • Feature Upgrade

Site Templates – reusable functionality that admins or end users could provision

  • Site Definitions
  • Web Templates

Continuous Integration and Testing

  • Plan and define the CI/Build process
  • Always consider how you will upgrade the solution
  • Define the unit testing and mocking requirements (Pex & Moles, TypeMock)
  • Funcitonal UI Testing (Selenium, Coded UI, Telerik Test Suite)
  • Always sync with the test team and what they do/how they will test your solution

To close off the talk I finished off with a few tips:

  • Build applications in such a way that makes you feel proud of what you have built. Doctors feel good when they help people, architects feel good when their creation is built, lawyers are happy when they get paid – there is no reason why SharePoint developers and architects shouldn’t feel good about what they do if they do it well.
  • Motivate your team to do good work – As an architect you are most likely a role model. Do your best to motivate your team members to be champions and get good stuff out there. Reward them for good efforts.
  • Change your job if your boss/architect/team leader/project manager is pressuring you to do crap work with no process around it, no scope, no clarity, no design, etc. Your SharePoint career is way to short for you to be doing crap work in crap teams. Only you could make that change.
  • Apply development practices and architecture to SharePoint solutions – many say that there is no real development in SharePoint. It’s true that there is a lot of “other stuff” in SharePoint projects, but for the development part – make it count.

Here is my slide deck: SharePoint Solution Architecture – Radi Atanassov

During my talk I showed bits of a solution I use to POC various SharePoint components. I use it to explain and demonstrate things to students, forums and colleagues. I call it Community.SharePoint and as soon as it has a few other key components I will post it on CodePlex.

Here is the version I used at the European SharePoint Conference: Community.SharePoint-EUSPC

Hope this helps someone!

“Activate on Default” confusion and features scoped at Web Application level

When creating SharePoint features in Visual Studio 2010, one of the settings that defaults to True is “Activate on Default”.


There is a lot of confusion as to what this setting actually does:

  • It ONLY applies to features scoped at Farm and Web Application levels. You can still modify it for other features, but it doesn’t do anything.
  • Any feature (Farm or WebApplication) with that setting set to True will automatically activate when you deploy the WSP solution, no matter which way you deploy it (Install-SPSolution, stsasm.exe, Central Administration)

This setting is not related to the deployment configuration settings in Visual Studio 2010:


These features will still activate, even if VS’s deployment configuration is set to “No Activation”.

Where can this be an inconvenience?

When you create features that deploy Timer Jobs at the Web Application level, you really want to have “Activate on Default” set to False. Otherwise, your feature will be activated on ALL web applications. I did some tests and found out that even if your WSP Solution is not global and is deployed to a specific Web Application, your feature will still get activated. Dangerous, you really want your Timer Jobs to be running where they are meant to run, i.e. don’t deploy Timer Jobs to Central Administration unless you really need to.

If you are ever trying to find out why your Timer Jobs are “attached” to all web applications, this might be why.

Fun with HTTP Handlers, Security Validations, FormDigest, AllowUnsafeUpdates, jQuery, AJAX and POST parameters in SharePoint

Ever seen this error message?

System.Exception: Microsoft.SharePoint.SPException: The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again.

It is usually related to a missing SharePoint FormDigest control, or updates to the DB on an HTTP GET request. You might hear people saying you should set AllowUnsafeUpdates to true, but in the case of a POST request that is not the best thing you could do. The best resource that you could ever read on the topic is written a while back (in 2008!) by a good friend of mine and ex colleague - Hristo Pavlov. These two posts are your best starting point if you want to understand what these items are for and how they achieve their purpose.

What You Need To Know About AllowUnsafeUpdates (Part 1)

What You Need To Know About AllowUnsafeUpdates (Part 2)

Generally speaking, AllowUnsafeUpdates = true on POST shouldn’t be required at all. I was working with my team on an HTTP Handler living in the SharePoint Layouts folder and it was failing with the security validation exception. In a typical ASPX web page you would include the SharePoint FormDigest control and SharePoint will handle it from there onwards:

<SharePoint:FormDigest runat="server"/>


You will notice the output of this control is a hidden <input> like this one:


<input name="__REQUESTDIGEST" id="__REQUESTDIGEST" type="hidden" value="0xDA527A96…A23,22 Apr 2011 14:17:06 -0000"/>


SharePoint will use this control (in particular the parameter __REQUESTDIGEST) and validate the “FormDigest”. You can explicitly call the SPUtility.ValidateFormDigest() helper method achieves the same. (See Hristo’s blog posts for more info on how it works). It basically takes the __REQUESTDIGEST value and validates it on the request object.


But in an HTTP Handler you don’t have the <SharePoint:FormDigest /> control as there is no ASPX. Developers can get the handler working by setting AllowUnsafeUpdates on the SPWeb object, but this should be avoided when it could (see Hristo’s post on why it is not good). If you are making a POST request, pass in the __REQUESTDIGEST and make sure you call the SPUtility.ValidateFormDigest() method before you do any DB updates.


If you want to call your handler asynchronously with AJAX, lets say with jQuery, this adds another level of complexity. You have to pass in the __REQUESTDIGEST parameter for SPUtility.ValidateFormDigest() to succeed. I personally found documentation on the $.ajax jQuery method quite poor, but here is a JavaScript example on how to use it and pass the __REQUESTDIGEST <input/> value:

function UploadFileAsync() {

    var listId = $("input[id$='hdnListID']").val();



        type: "POST",

        url: "/_layouts/Handlers/FileUpload.ashx?ListID=" + listId,

        contentType: "application/x-www-form-urlencoded",

        data: "__REQUESTDIGEST=" + $("#__REQUESTDIGEST").val(),

        timeout: 30000,

        success: function (response) {



        error: function (x, t, m) {

            if (t === "timeout") {

                alert("got timeout");


            else {






A few things are important and worth mentioning. In the “data” parameter I get the value of __REQUESTDIGEST and pass it in the POST request. (NOTE: you may want to improve the $(“#__RE..”) selector to get only input/hidden elements and be better performing). This will allow SPUtility.ValidateFormDigest() to pass successfully. If ever in doubt, open the request with Fiddler and validate the contents, you should see something like this:


The other important point is the contentType parameter. For me this did not work when set to “text/plain; charset=utf8”. I didn’t have enough time to figure out why, but “application/x-www-form-urlencoded” succeeded successfully.

Hope this helps!

Как да изберем консултантска фирма?

Мойте съвети за всеки, който възлага проект към консултантска фирма:

·         Проучете хората, които ще работят по проекта – от колко години са в фирмата, какви са им отговорностите, по какви проекти са работили, какъв е перформанса на всеки от тях и защо са подходящи за ролята по проекта. Срещнете се с всеки един от тях.

·         Кой е лидерът на проекта, който отговаря за цялостния процес, комуникация и project management?

·         Кой е архитекта, отговорен за техническата посока и качество на изработка? Той в състояние ли е да води екипа и има ли техническите познания?

·         По колко други проекта работи всеки един от участниците? Имате право да знаете.

·         От предложението на консултантската фирма, ясен ли е процесът на работа? Той включва ли прототип, анализ на бизнес изискванията, документ който ги потвърждава, фази на проекта, план за тестване и премахване на бъгове, реалистични срокове? Гаранция?

·         Какви сертификати има фирмата и работниците по проекта? Това е спорно изискване – всеки може да има ISO 9001 и MCP сертификати, и работата пак да е некачествена. За мен тези неща не показват знания и опит, но показват дисциплина – някой се е захванал и отделил време да свърши една работа. Хубаво е, когато това е систематично – ако всичко е реализирано в близки дати, най-вероятно е постигнато за определена цел, като спечелването на определен проект.

·         Готови подобни решения – консултанта има ли такива? Обадете им се, попитайте ги как се чувстват относно решението. Доволни ли са от цялостният процес и ангажиране? Това може да се струва коварно на някой, но е често срещана практика в чужбина. Всеки има право да знае.

·         Качество на документите на консултантската фирма – това показва колко е организирана една фирма, и колко сили полага в изглаждането на детайли. Разгледайте офертите и предложенията – има ли правописни и граматични грешки, документа форматиран ли е добре, добре ли описва темата на комуникация? Вобще личи ли си професионализъм, или работата е джаста-праста?

·         Попитайте фирмата дали ще има подизпълнители. Имате право да знаете, но ако има ситуацията се усложнява. Кой е отговорен за какво? Зависими ли са всичките участници?

Ако има нещо нередно, отидете при следващата фирма. В крайна сметка Вие давате парите и имате право на избор.

Ради Атанасов
Консултант, архитект и разработчик на SharePoint решения.

Цената на upgrade – не я пренебрегвайте!

Една от най-важните качества за всяка нова версия на всеки нов продукт е начина на ъпгрейд от предишна версия. Същото се отнася и за внедрени решения на която и да е платформа. Целта на нови версии на софтуер е да носят нови възможности от които модерният бизнес се нуждае. Системи с които се интегрира едно решение също може да се нуждаят от подновяване, или дори нов хардуер. IT светът е много динамичен, няма спор. Искам да си кажа мнението за цената на ъпгрейд и как един текущ проект задължително трябва да вземе тази цена в предвид.

Много компании не предвиждат цената на подновяване на едно решение. Сблъсквал съм се с клиенти, които се интересуват от пълната цена сега на момента, и винаги гледат тя да е най-минилана, като се отстраняват всички допълнения към един проект освен директната разработка. Но ако не се вземе в предвид цената на подновяване и променяне в бъдещето, да кажем след година, тази цена е напълно безсмислена. Според мен всяко решение трябва да бъде създадено с мисълта за ъпгрейд, разширяване и подновяване. Трябва да има документация, качествена архитектура, МНОГО качествен код, план за възстановяване след дизастер и всичко да е минало през пълноценен тест –именно тези неща се пренебрегват. Всичкото това струва пари, но добрият управител трябва да му е наясно защо се правят тези неща. Ако един мениджер не му е ясно и няма опит с IT проекти, абсолютна отговорност е на консултанта да обясни тези неща.

Защо качествен код? Защото некачествен код не се разширява, а се пренаписва! Ако имах всички долъри, които бивши клиенти биха спестили с намирането на малко повече финанси за надценката за високо качество на работа, щях да мога да купя Африка и да нахраня целият им народ.

Ето пример: случвало ми се е много често да работя по проекти, където липсва добра аркитектура, а самите хора които са писали кода ги няма. Решението гърми и дава грешки, а хората са си взели парите. Клиентът е недоволен, защото бизнеса му се разширява и допълнителната тежест над решението е необмислена. И какво казват новите разработчици, които поемат ъпгрейда: кодът е много зле написан, няма документация, архитектурата е слаба и трябва да се пренапише. А системата дори не е тествана за извънредни ситуации... Най-големия ужас, за човекът който е дал парите за този проект преди година. Дали преди година тези неща са взети в предвид?