Speaking at SharePoint Connect in Amsterdam


I have the pleasure to speak at the upcoming SharePoint Connect conference in Amsterdam about

SharePoint Continuous Integration with VS Online and Azure


With the Cloud Services Azure and VS Online professional SharePoint Development has never been easier.

Having the infrastructure available on demand and only paying per use allows you to build complete production-like SharePoint farms in no time at minimal costs.
VS Online on the other hand provides everything you need to develop projects alone or in a team.
SourceControl, WorkItems, TeamBuild, Automated Testing including the traceability of all of it and detailed reporting.
Even better, with an MSDN subscription both VS Online and Azure is already included.

This session will show you how to

  •  use VS Online to automatically build your SharePoint solutions and apps
  • automatically deploy your SharePoint solutions to the staging farm with VS Online
  • automatically deploy your Provider Hosted Apps to SharePoint Online and Azure

You will receive a 10% discount on the conference registration fee when using my discount code SA336.

If you like to meet up there to talk or to claim one of our awesome SPCAF stickers :) either find me or contact me to arrange a meeting.


Enforcing Good Development Practices in SharePoint

When building out SharePoint systems more often than not some element of custom code will be involved. This is especially true if the requirements are challenging or don’t quite stick to traditional ‘out of the box’ SharePoint behaviour. In SharePoint 2013 this could mean the use of JavaScript, C#, VB.Net, even PHP or Ruby to build customizations.

The quality of these customizations, and the code used to build them, can have a huge influence on different aspects of the SharePoint platform:

  • Security: Poorly written code can introduce security flaws that are hard to detect.
  • Performance: ‘Better code equals better performance’ is so often true. Bad code can have a big impact on the speed of the final application.
  • Maintainability: ‘Spaghetti code’ might get the job done and fulfil the requirements for now, but makes it really hard to apply changes in the future.
  • Stability: Badly written code can have hard to find bugs, which decreases stability and can result in more errors.

In the past SharePoint code could only be deployed as a ‘full trust farm solution’. Microsoft Premier Support, the helpdesk for SharePoint professionals, received more calls caused by badly written code in farm solutions than almost anything else. Microsoft needed a better approach. After the first rather unsuccessful halfhearted fix called “Sandboxed Solutions” they introduced the ‘App development model’ in the latest version of SharePoint. With Apps their code is not run on SharePoint servers, and thus a lot of problems listed above simply can’t occur (plenty of others arise, but this is a different story).

The ‘App model’ permits only client side code (e.g. JavaScript) or server code running on an entirely separate platform away from SharePoint. For example, a SharePoint App can be written in PHP and hosted on a separate Linux server, but then be called from and exchange data with the SharePoint platform.

In any development scenario, even those still using full trust solutions, good development practices are hugely important. This blog post will outline several  strategies that can increase the quality of code in your SharePoint applications.

1. Choose the right SharePoint development pattern

Full trust solutions

Full trust farm solutions are very well alive and certainly will be around for many many more years. Microsoft has committed itself to deliver SharePoint on-premises releases in the future and for some organizations this might the only viable option.
This development pattern we are using now has been well-establish since SharePoint 2007 and is the most flexible and powerful way to customize SharePoint. But with great power comes great responsibility. Too many things can go wrong in full trust world as described in my article “Five reasons to avoid ‘Full Trust’ solutions in SharePoint”.

Nowadays, I avoid them as much as possible and try to find a solution for the business problem with an app, or at least with minimal usage of server side code. By this you can assure that future upgrade of SharePoint or a migration to the cloud will have minimal impact on your code.

Sandboxed solutions

Sandboxed solutions were the first attempt by Microsoft to address the downsides of full trust code. They run in a secure, monitored process that has access to a limited part of your SharePoint farm. Naturally this means also limitations to what you can do with them. Read more about that in the “Sandboxed Solution Considerations” on MSDN. With SharePoint 2013 and the dawn of the app model, Microsoft deprecated the use of managed code in sandboxed solutions meaning that you should only use them to deploy declarative code like content types, fields, list definitions etc.

It is pretty clear that Microsoft will not invest anymore in sandboxed solutions, so rather avoid them if possible.


SharePoint Apps come in two forms: ‘SharePoint hosted’ and ‘provider hosted’. Provider hosted apps are usually more complicated, due to the fact that an external system is involved, but offer a wide range of hosting and coding options. SharePoint hosted Apps are rather straight forward but only JavaScript can be used to write customizations.

It is really important to choose the right pattern upfront, because it is harder to change when development has already started. Microsoft has published an excellent article that should help make this decision easier.

2. Design patterns and methodologies

A wide range of design patterns have been developed and documented over the years. They offer a great insight to the fundamentals of writing quality code. By following a design pattern, code should be more maintainable and readable. The Model View ViewModel is a classic and excellent example, one where logic code is separated from that needed for the user interface.

Dependency Injection and Inversion of Control are also popular patterns and techniques to build loosely coupled systems where components can easily be replaced.

Looking into the brave new SharePoint app world models like ASP.net MVC (Model View Controller) and Angular.js MVW (Model View Whatever = MVV or MVC) seem to have become widely accepted. Still many development scenarios and patterns on top of that, which we got used to do not work anymore, or work differently. Hence, Microsoft and several volunteers of the SharePoint community are providing an Open Source project collecting and refining Patterns & Practises to solve these common problems. I would recommend anyone developing apps to check out their code on GitHub to see if there is already a solution for your problem available that can be re-used.

In general the choice of a model mostly depends on the experience of the developers building the application, but the key thing to remember is that a proper software design will result in better code.

Use a model where one exists and makes sense, but not just for the sake of it. Wise words, I know ;)

3. Implement regular code reviews

Developers make mistakes. And everyone struggles when reviewing their own work. So independent code reviews should be held regularly and made part of the development schedule. They will help to detect and mitigate mistakes, and can be as simple as asking the developer in your team to look over things.

Code reviews can be performed in many different ways eg. Over-the-shoulder, pair programming, tool assisted etc. but, because of the human involvement, they all have in common that they will help you to improve the quality not only from a technical but also from a functional point of view. This is something no automatic code review can compete with as it just does would not understand the purpose of the piece of software (unless you teach it to explicitly).

As a side effect, code reviews help the team to learn from each other building up a common skillset and eventually a more uniform and easier maintainable code.

4. Analyze your code for quality

During development, it is a good idea to use a dedicated tool to analyze code. For example, our own SPCAF will analyze the code against 600 quality rules and generate a report detailing its findings. Fixing the issues highlighted will increase performance, maintainability, and stability and save you lots of time and trouble already before your code is deployed to the production environment.

One thing you have to be aware though is that whichever tool you are using it will never be the silver bullet. A tool can only check against rules that exist and there are always plenty additional practices and errors that could be validated. Also, especially in SharePoint development, many coding practices depend very much on your target platform and your own practices and corporate guidelines.

Let’s just think about the everlasting fight between declarative and programmatic approach in full trust farm solutions. Declaring for example content types in XML was long considered to be the better (though harder to debug) way compared to using a feature receiver and coding the content type in C#. Both approaches have there advantages and a tool can recommend and validate either one, but at the end you have to define which is the better one for you.

Hence tools like SPCAF provide configurable rulesets allowing you to adjust the analysis to your requirements, as well as a Software Development Kit (SDK) to implement your own rules checking your specific patterns and practices.

When you have done that, the tool can help you to make sure you remain consistent throughout your solution or projects.

Making good code even better

One problem with writing quality code is that it is difficult for an outsider to detect the quality between ‘good’ and ‘bad’ code. Bad code might fulfil the requirements, it might do the job in hand, but it could create issues in the future. Bugs could have been be introduced that can affect the performance, and they might not be apparent right away.

At the same time ‘good’ code can generally always be improved. It can be made more performant, can be streamlined, or take advantage of new techniques and approaches. The SharePoint App model is a good example. Lots of full trust farm solutions contain excellent code, written in a professional way, but the App model is still a better future-proof approach.

Either way it is always a good idea to put more effort into design, analysis, and review of code upfront. This way the quality of the code will improve, and so too will the quality of the solution – which is ultimately what everyone wants.

SPC Adriatics 2014 recap and slides

Last week I had the pleasure to speak at the “Probably best SharePoint conference in the world” SPC Adriatics in Zagreb, Crotia.
Being a conference organizer myself with SharePoint Saturday Stockholm, I have to congratulate the team Nenad TrajkovskiAdis Jugo and Toni Frankola to deliver a perfect event which does not have to hide from any other commercial conference I know of.

On the contrary, being a speaker, there has never been and event where I was so well taken care of in regards of accommodation, food, drinks and lots of friends around me. Just awesome! Thank you!

I had the pleasure to talk about two of my favorite topics:

Assuring the Code Quality of SharePoint Solutions and Apps

SharePoint Continuous Integration with VS Online and Azure

You can find the code for the SharePoint solution PowerShell Script I used on GitHub and on the corresponding CodePlex project of the SharePoint Solution Deployer (SPSD).
The HowTo “Deploying Provider Hosted SharePoint Apps to Azure” can be found Kirk Evans’ blog

Thanks everyone for attending! Hope to see you again next year!

SharePoint health check (3): Auditing Customizations

This post is the third of a series explaining how to audit your SharePoint farm.

Analyzing the Customizations

In the previous post we retrieved all code customizations with the help of a little PowerShell script. In order to analyze them,

  1. Go to your machine where SPCAF is installed (SPCAF does not require SharePoint or Visual Studio when analyzing in the client application).
  2. Start the SPCAF client application
  3. Navigate to the network share where you stored the extracted files
  4. Drop one, several or all of the customizations from your farm into the center of your application

    Analyze your WSPs and Apps

    Tip: Analyzing all customizations at once will most likely overwhelm you with the sheer amount of findings, so better only combine the ones that seem to belong together (eg. similar naming, similar source location) as they might have dependencies to each other. Analyze the all others separately.

  5. Click the advanced settings in the client and adjust which rules should be applied, e.g. by selecting an existing or your custom pre-configured analysis settings created with the settings editor.You can also select the different report type that should be created including HTML, DOCX, PDF, XML, CSV or DGML (for dependencies)


    Advanced configuration

  6. Start the analysis and let SPCAF gather the information. This may take a while depending number, size and complexity of the solutions you are analysing.
  7. When the analysis is completed you will be presented an overview dashboard allowing you to navigate into the different results or download the generated report documents.

    SPCAF Analysis Dashboard

    SPCAF Analysis Dashboard

Reviewing the Results

SPCAF will highlight if and where there are problems and give guidance how they can be resolved.

Code Migration Assessment

Code Migration Assessment Report

Its reporting can be broken down into the five areas:

Code Quality

SPCop200x200The code quality analysis validates the code against over 600 rules that vary by severity, the most serious being Critical Errors and Errors. This includes quality rules in categories like Correctness, Security, Best Practice, Localization, Memory Disposal, Performance, Deployment, Syntax, App Store Compatibility and many more.

Note: As it is common with SharePoint there is seldom only one truth. The validity of a many reported violations depend very much on your target environment, the allowed customizations, your internal coding policies and preferences.

Full documentation

Code Metrics

SPMetrics200x200The code metrics can be used to evaluate the complexity, maintainability and migratability of the solution packages and apps. It won’t give a list of easy to follow errors, but it gives a good summary of the structure of the solution helping you for example to calculate migration efforts.
Full documentation

Code Dependency

SPDepend200x200The dependency analysis detects all dependencies between elements in the code and to external components, like references to DLLs, features, JavaScript Frameworks etc.. This can help you to review and improve the solution architecture or to pinpoint missing assemblies or files on your SharePoint farm which causes problems with the solution.
Full documentation

Code Inventory

SPInventory200x200The inventory provides a summary of the contents of the solution. By this you can create a standardized documentation which can be used as reference e.g. when resolving issues found in the ULS logs of the farm, or getting an overview in order to plan a migration to a new SharePoint version or the cloud.
Full documentation

Code Migration

SPCAF_MAThe code migration assessment is a combination of the four analysis view described above, focussing entirely on giving you guidance how to migrate a full trust code solution to the SharePoint app model. It highlights potential road blocks which prevent a 1:1 migration and describes alternative ways to implement a similar functionality.
Full documentation

Seeing is believing so check out one of the sample reports: 

Code Migration HTML DOCX PDF XML

Looking towards a future in the Cloud

Although there is no quick fix to a healthy stable SharePoint farm, using tools like SPCAF and SPDocKit can help start the process. As Microsoft moves ever more to the Cloud, and the new SharePoint ‘App model’ for custom code, understanding how current solutions are structured will become more and more important. We designed SPCAF to help people on this journey, and would love to hear your experiences in the comments below.

SharePoint health check (2): Extracting Customizations

This post is the second of a series explaining how to audit your SharePoint farm.

Extracting Customizations from the Farm

PowerShellWhen auditing the customizations of your SharePoint farm, the first step is to retrieve all of them in their currently deployed versions.

This can be achieved by some PowerShell code executed on one of the farms servers.

  1. Log in to one of your server on your SharePoint farm (you will require farm administrator permissions)
  2. Create a local folder to store the customizations.
  3. Open a SharePoint Management Shell (PowerShell) window and browse to that new folder.
  4. Extract all WSPs and/or Apps from SharePoint by running the following PowerShell scripts
    • Full trust farm solutions
    • Sandboxed solutions (from a single site)
    • SharePoint Apps (from a single web)
  5. Copy the folder with your customizations to a network share, which is accessible from where you run SPCAF

I want them all!

The code above just illustrates how to get solutions and apps from a single instance of a site or web.

To extract all code customizations from the farm you can use the following complete script. It retrieves them from all sites and webs which are accessible by the account executing the script.

It creates a folder named after the current date, subfolders for full trust solutions, sandboxed solutions and apps as well as subfolders for each site or web that contains a customisation.


Folder structure

During execution it logs the processed sites, solutions and apps.

Without further ado, her comes the complete script

The entire script can be downloaded from GitHub

Great, what now?

Now that you have extracted all code customizations you might wonder what to do with them.

» Read on at “SharePoint health check (3): Auditing Customizations”