Alexander Vanwynsberghe

"There is nothing impossible to him who will try"

Debugging TFS Web Access Extensions

Last week I was working on some TFS Web Access extensions. For those who don’t know what this extensions are all about, just try the ‘Task Board Enhancer‘ by Tiago Pascoal and be amazed by the power of it. In short:

In Team Foundation Server 2012 (and 2013) you can develop extensions for the web interface, the extensions are Javascripts that can easily be installed using the TFS Web Access Control Panel. You can create plugins using the Javascript Object Model of TFS. An example can be a custom Work Item Control that can be visualized on the Web Access. More info and some how-to’s here.

Read More

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