Presenting at SharePoint Saturday NL 2015 Event

On June 6th I have the pleasure of presenting at the annual SharePoint Saturday event in the Netherlands. This will be my very first time presenting at an event, so I am very much looking forward to it! Below you will find the outline of the session I’ll be presenting. Hope to see you there!

Introduction to developing remote event receivers (level 200 developer)

SharePoint 2013 introduced the concept of remote event receivers. These remote event receivers enable you to build apps that can tap into common SharePoint events and perform additional actions when they occur. But how do you build an app that utilizes remote event receivers and how can deploy your app to Azure?

This session will provide in depth knowledge on how to get started when developing remote event receivers. Aimed specifically at developers, we kick off with a brief introduction on the concept of remote event receivers. Using real-world examples, we’ll demonstrate the different possibilities for creating remote event receivers and explain the different kind of permissions your App needs in order to use remote event receivers. In the end you will learn how to deploy a remote event receiver to Azure.

When this session is over you’ll know all you need to know in order to get started building your own apps using the cool new capabilities that remote event receivers offer you!

Debugging a solution with multiple SharePoint Apps

In a very large environment it is not uncommon to have Visual Studio solutions that contain multiple different projects. However, when you’re working with these individual projects, you want to be able to quickly debug your specific project. I recently discovered, that when you do this in a solution that contains a Provider Hosted App, switching to and from the Provider Hosted App for debugging purposes, has some very specific gotcha’s…

Let’s create an example to see what I mean. I create a new solution with a provider hosted app (ASP.Net Web Forms Application). After the solution has been created, I add an additional project. This time it’s a console application. The solution structure, still very basic, now looks like this:


Let’s say I’m going to work on the Console Application first. So I right click on the project and select ‘Set as startup project’. I hit F5, and the console app launches and everything is working great. The debugger is properly attached, and my breakpoints (if I’d have any) are properly hit.


Now the Console application is absolutely perfect, and I want to continue working on my Provider Hosted Application. This is where the trouble begins… Which project do I set as startup project? First let’s see what happens when I set the PHApp project as startup and hit F5. So far so good… Visual Studio installs my app in my SharePoint site, launches IE and reverts us back to the apps default page. However… None of the breakpoints set in my PHAppWeb projects are being hit. Sure, IIS Express launches the web and handles the execution, but not being able to debug through your code makes things quite difficult doesn’t it?!

Breakpoint not hitting

Let’s see what happens when we set the PHAppWeb project as the StartUp project. I hit F5 once again, and great; my symbols have now been loaded! But wait… nothing else happens. Your default browser is not starting, and there is no way for us to reach the code unless we want to manually browse to the apps’ start page. That’s no good either!

So, what other choice do we have? The answer is in the solution properties. Right click on the solution and select ‘Properties’. In the ‘Startup project’ tab, you have the option to select multiple startup projects at once. So let’s select that option, and specify the PHAppWeb first with a ‘Start’ action, and the PHApp second, also with the Start action configured. The end result should look like this:


Now when we hit F5, the PHAppWeb is launched, symbols are loaded, and then the app is installed to SharePoint. Once that is done, the browser will start up and asks you to trust the app and then redirects to the apps’ start page. Exactly the way we want it to! Unfortunately, you’ll have to manually change this every time you set a different StartUp project.

So, in short, if for whatever reason your Provider Hosted debugging experience is a bit buggy, make sure to check the Solution Properties and check if both the AppWeb and the App project are configured with a ‘Start’ action. Gotcha!