IT Pro fear no more! Introducing the SPCAF PowerShell CmdLet

Attention IT Pros!

This time we have something for you!

PowerShellWe are happy to announce the availability of the new SPCAF PowerShell CmdLet enabling you to analyze the code quality of your SharePoint solutions (.wsp) and apps (.apps) in your solution deployment scripts, your farm health checks or anywhere else you are using PowerShell to automate SharePoint management tasks including migration and governance solutions like AvePoint’s DocAve, Metalogix Content Matrix or Sharegate’s Sharegate :)

SPCAF PowerShell includes the same five analysis components as the the full client for Code Quality Analysis, Metrics, Dependency Analysis, Inventory and Migration Assessment.

With the PowerShell provided scripts you can download all WSP solutions and apps and check them against over 600 code quality rules. The generated reports show you if the solutions are well developed or contain issues which may harm the performance, supportability and stability of your farm.

Get a free Code Quality Summary Report

If you don’t own a license SPCAF creates a free summary report (HTML) that highlights the found issues and their categories and summarizes the code metrics.


SPCAF Summary Report

Integrate the Analysis into your Solution Deployment Process

SPSDIf you already use PowerShell to deploy solutions and apps to SharePoint, for example with the help of our free SharePoint Solution Deployer (SPSD) script, then you can easily integrate the SPCAF analysis into your deployment process:

Run the analysis right before the customizations are deployed to SharePoint and stop the deployment if critical issues have been identified. This ensures a better code quality of your deployed solutions and apps and improves stability, performance and security of your SharePoint environment.

How to use SPCAF PowerShell

Using SPCAF PowerShell is very straight forward. After importing the SPCAF.PowerShell.dll module you can invoke an analysis for a single solution or app or for a complete folder.
You can pass your custom ruleset configuration to adjust which rules are checked as well as define the output formats and the report location and name.


To make your life easier the download already includes two sample scripts to show you how to

1. AnalyzeSolutionsLocally.ps1

 2. LoadAndAnalyzeSolutionsFromSharePoint.ps1

If you like to download additionally apps and sandboxed solutions from your farm for the analysis, then check out my blog on how to extract all customizations from your farm in which you will find the required PowerShell script.

Command Line Parameters

SPCAF PowerShell comes with a range of parameters that allow you to configure the analysis to your needs.

Parameter   Value   Mandatory   Description  
InputFiles String Array Yes List of input files or directory for the analysis. Support formats: .wsp, .app, .dll, .exe, .zip.
LicenseFiles String Array No Optional path to SPCAF license files. If no license file is given only the free feature are activated.
SettingsFile String No Optional name or path to the settings files (.spruleset) which defines the analyzers for the analysis.
Reports String Array No List of report formats which should be generated during the analysis. Possible values: HTML, PDF, DOCX, XML, CSV, DGML.
OutputFile String No Optional path the output file. The reports will be written to the same location as the output file in the various formats.
Verbosity String No Optional level for verbosity to limit the detail level for log messages. Valid values are: quiet, minimal, normal, Default
TempDirectory String No Optional path to the temp folder.
SkipProjectCreation Boolean No Optional Boolean. Default FALSE. If TRUE no project (.spcaf) file is created as output of the analysis.
TimeOut Integer No Optional seconds after the analysis should be cancelled automatically.


Apart from generating the detailled reports, SPCAF PowerShell outputs the number of issues to the console and provides the gathered information to the PowerShell pipe for further processing eg. to cancel the deployment.

Note: The number of issues is also available when running SPCAF PowerShell without a license making it easy to integrate in in every deployment process.

Sample Output:

Try it now!

You can download the SPCAF PowerShell CmdLet from the TechNet Galleries

Download the SPCAF PowerShell CmdLet


We would be very happy to hear your feedback about how you are using SPCAF PowerShell, so please tell us your experiences and feature requests either in the comments below or by mailing us to

Thank you!

5 things to remember when migrating to Office 365

office365Many companies are thinking about moving to the Cloud, and this includes SharePoint clients. Microsoft is pushing the advantages of Office 365 to its customers, and many are finding its wealth of features offer a good argument to either move away from existing ‘On Premises’ solutions entirely or set up a hybrid environment which leverages both the benefits from the cloud and on-prem.

There are several advantages in using Cloud systems – including flexibility of functionality, lower start up and ongoing costs, and ease of maintenance. Yet migrating to the Cloud is not always easy, especially when it comes to SharePoint. Many companies still have legacy SharePoint systems which include customizations and lots of content. Not all of these customizations will work in the Cloud, and content migration requires a good deal of proper planning and thought.

Moving to the Cloud can be complex

Migration projects are inherently difficult, and they shouldn’t be undertaken lightly. To test if your organisation or company is ready here are five questions that you should be able to answer positively before attempting an Office 365 migration.

1. Have you audited the current system?

An audit of your current implementation consists of two things:

  • Audit your content: Which content is still valid and which needs to be migrated? Take this chance to delete or archive content that is no longer required in the new system.
  • Audit functionality: Which custom functionality in the existing SharePoint system needs to be migrated? Look at all the options – like farm solutions, custom site templates built using the browser, custom workflows in SharePoint Designer, etc. Office 365 offers new functionality that can often replace custom functionality altogether. Your system will be all the better for using Office 365 native functions as much as it can.

2. Have you audited custom code?

Over the years, it is likely that a lot of custom code has been deployed to your SharePoint farm. If your system has been running for a while you might not even be aware of which customizations are running and even who built them.

It is important to realise that not all customizations can be migrated to Office 365. For example, full trust farm solutions are not supported. Even more you might realize that some of your customizations might not be required anymore or the underlying business need has changed. Thus a re-design might be necessary anyway.

Analysing your customizations manually is extremely time-consuming. Try our our free SPCAF Migration Assessment tool. It generates detailed report about customizations in your farm in a couple of seconds, helps you to understand what they currently do and guides you to migrate them to the app model!

3. Have you thought properly about content migration?

When you know which content you want to migrate, you have to answer the question: How are you going to migrate that content?

Office 365 offers the Explorer View, which allows you to open a SharePoint library in Windows Explorer. This is suitable for small migrations, but lacks certain key functionality like migrating metadata and incremental migrations.

3rd party options like Sharegate and a number of other products help you to migrate your content to Office 365 much easier.

4. Have you thought about long term maintenance of the new solution?

The implementation of the new solution in Office 365 is a good moment to not only think about the migration, but also about the future:

  • How is content going to be maintained? Will there be a dedicated Intranet Manager or team in place to manage things?
  • How are customizations to be maintained? Even though in Office 365 there is no longer a farm to maintain, customizations need to be monitored and maintained. SPCAF can analyze custom apps and sandboxed solutions deployed to your Office 365 and provide detailed reports about maintainability, code quality, and dependencies.

5. Have you talked to your users?

The most important people in a migration project are the users of the SharePoint system.

By organising workshops with key users, their thoughts about the current and the new solution can be fully understood. Current functionality and content can be discussed and the advantages of new functionality in Office 365 can be demonstrated.

This way users will feel engaged, which helps to increase the popularity of the new implementation. It is generally a good idea to keep everyone in your organisation in the loop as much as possible. Not only by sending emails, but also by organising presentations, demos, workshops, etc. People are key to a good migration.

Preparation is key

A migration project can be complex and requires proper preparation. When a migration is not prepared well, it will most likely fail. Analyze your content and customizations thoroughly, inform and discuss the migration with your users, and develop a migration strategy. Don’t forget to update your users regularly. People in general don’t like changes, so by informing them in advance of change they feel more engaged.

Our own SPCAF can be used to understand and analyze any customizations in the ‘On Premises’ SharePoint environment, as well as migrate and maintain them in Office 365.

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 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!