Alexander Vanwynsberghe

"There is nothing impossible to him who will try"

Debugging SharePoint 2013 remote events using the Windows Azure Service Bus

In this post, I will talk about how you can debug remote events within a SharePoint 2013 App. Especially with the Autohosted App Model (I made a post about that a while ago). Let me first start with a small and really easy to understand app that I will use to highlight the topic of this post.

The App

It’s quite an easy app where you can:

  • Add a contact
  • Get a contact

The App has some logic in the Web project (to manage the button “Add Contact” and “Get Contacts“), and a “List” in the SharePoint project. You will find the sources at the bottom of this post. When running this App, you will see something like:

03

As you can see, the “FullName” contains the text “Not set!“. That’s correct, I only provided my first and last name. But I want my full name to be “managed” by a remote service. And that’s where this post is all about. Finally! What I want is a remote event receiver that will be triggered when a new contact has been added. Add one to the SharePoint project. Right-Click and select “Add – New – Remote Event Receiver”. Call it “Contact List“. You need to select the type of event on which the event receiver needs to do something. Select “An item was added“.

02

You will now see a new folder in the Web Project called “Services“‘ and a new service called “ContactList.svc“. When you open it, you should see 2 methods. The one we need is called “ProcessOneWayEvent“. You can add the following code:

What it actually will do is get the ClientContext and get my first and last name that I submitted. It will than perform a string merge and add it to the “FullName” of the ListItem. Nothing fancy. So, why don’t we just hit F5 and check it out? You will soon find out that it will not work, the service is not being called. You can try to add a breakpoint, and you will see that it will be ignored. But why?

Problem

The problem is quite easy to understand. What will happen when you press F5 is a “Publish” of your App to SharePoint online, and once you “Trust” the App will eventually loop back to your “Local IIS”  (as you can see in the URL of the screenshot at the beginning of this post). It looks like:

problem1

So our Web project is running locally, meaning that our web service is also running locally. So in our case, when we hit the button “Add Contact“, it will try to call our Remote Event Receiver. So from a  SPAppWeb (which is SharePoint Online) context, it will not be able to contact “Localhost“. It looks like:

problem2

Solution: Windows Azure Service Bus

In the final “RTM” version of Office Developer Tools for Visual Studio 2012 there is cool feature called “Enable Remote Event Debugging“, making use of the Windows Azure Service Bus. Now first of all, what’s that Azure Service bus? Let me take the description from MSDN:

The Windows Azure Service Bus provides a hosted, secure, and widely available infrastructure for widespread communication, large-scale event distribution, naming, and service publishing. The Service Bus provides connectivity options for Windows Communication Foundation (WCF) and other service endpoints – including REST endpoints — that would otherwise be difficult or impossible to reach. Endpoints can be located behind network address translation (NAT) boundaries, or bound to frequently-changing, dynamically-assigned IP addresses, or both.

In other words, the Windows Azure Service Bus allows you to expose our local WCF service to the “outside world”. And that’s exactly what we need! All you have to do is get yourself a Service Bus instance and enable this feature in the SharePoint App project properties. You can get a Windows Azure Service Bus  instance using the Windows Azure Management Portal. On the left side, click on “Service Bus” and click on the “Add” sign on the bottom of the page. Add a name, and finish the wizard.

06When your service has been created, all you have to do is click on the “Access Key” button and copy the connection string. Next, right-click on your SharePoint App project in Visual Studio and select “SharePoint“. There you can “Enable Remote Event Debugging“:

08

Now you can add a breakpoint in your service code and press F5. There you go:

09And if you look at the App itself, you will see that the “FullName” has a value:

10

Mission accomplished! You can download the sources here. Have fun! Oh, and just a small note, did you know that you can actually see which services are available/active on you Windows Azure Service Bus? Just browse to the URL of your service bus, and you should see:

04

Building SharePoint 2013 Apps with TFS 2012

In this post, I want to talk a little bit more about how you can build those shiny new SharePoint 2013 Apps using a TFS 2012 build server, but especially: without installing Visual Studio! To start, I will shortly guide you trough the process of setting up a TFS Build Server (with 1 controller and 1 agent).

You might be wondering, why do you setup a separate TFS Build Server? Why don’t you just use the Hosted TFS Build Server? Well, that was also my intake, but it just doesn’t work (yet). The Hosted Build Server does not have the “Office 2013 and SharePoint 2013 Developer Tools” on it, so it’s not able to build SharePoint 2013 apps. So for now, a separate server will do the trick.

TFS 2012 Build Server

Let me start with a quick overview of how to setup a TFS 2012 build server. In my scenario, I’m using a fresh Azure-hosted Windows Server 2012 VM. Fast and easy setup. Download the TFS 2012.1 installer and start the ‘Build Service Configuration Wizard’:

01The next step is connecting to your TFS Team Project Collection, which is a TFS Service (VisualStudio.com) instance.

02The next few steps are just a ‘next-next-next‘ experience, use the default settings as they are provided. Once you’re ready, you should see that it has one controller and one agent connected to your TFS Server.

08

CI Build Definition

Now comes the tricky part, how can be build SharePoint 2013 Apps without installing a full-blown Visual Studio 2013? Which components do you need? Well, we’ll start by creating a Windows Azure Auto Provisioned App like I’ve described in another post. Once you have this app, add it to Source Control, and perform a check-in.

Next step is to create a build definition which will perform a continuous integration build of our app. Using Visual Studio, go the the ‘Builds‘ section of Team Explorer, and click ‘Create New Build Definition‘. Give it a name and select ‘Continuous Integration‘ as trigger.

ci1

On the ‘Build Defaults‘ section, select the Build Controller we’ve just created, and define where you want the drop output  to be stored. I will just use a drop folder in Source Control (which is a new feature in TFS 2012).

ci2On the process section, select the solution file, and leave the other settings by default. That’s it for the build. To try, just queue the build manually, and you should see a nice failing build. That’s completely normal of course, as we didn’t install any build-related things on the build server yet:

error

Required components

Now that we have the build, we need to make the necessary changes on the build server (where the actual Build Agent service is running). Install the following components in the right order:

That’s a tricky one. It will start the web platform installer, and it will give you this error:

10

That’s correct, we don’t have Visual Studio installed, and that’s exactly what I don’t want! But when you click OK two times, you will a nice overview of all components required:

11

We can now use the Direct Download links provided to install the required components:

When installing this, you’ll get another nice warning about the ‘Microsoft Web Developer Tools’. Just click ‘Continue

13

There we go, another nice screen telling me that I need the Windows Identity Foundation Runtime.

16

My build server is a Windows Server 2012 machine, and there you can ‘enable’ the WIF runtime as a feature on that machine. When you enabled this, just retry the setup of the WIF SDK.

17

Almost there! If you queue a build now, you will see the following nice error:

error2Correct, that piece is missing on the build server. To solve this, all you can do is ‘copy‘ the folder ‘C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications‘ from your development machine to the Build Server (on the exact same location). That should do the trick! If you now queue your build, you will get:

buildokThat’s it, you have your SharePoint 2013 building on clean, fresh Build Server without installing a full-blown Visual Studio 2012. It was quite a challenge, but thanks to Xavier Decoster and some research I managed to get this thing working!

In a next post, I will explain you how to build an APP package with the TFS Build Server. It’s not that simple as just adding “/p:IsPackaging=True” as extra ms build argument unfortunately.

Thanks!

Some extra information: In case you are wondering why I install the Windows Identity Foundation SDK (Dependency)? You can just use the .NET 4.5 Framework, and WIF is already in there. But you need to have the WIF SDK 4.0 to be able to install the WIF extensions. So… You just have to know..