Recently I’ve been working with a provider hosted SharePoint App. The objective of the app is to register a remote event receiver on a library in the host web, and then handle events from it. There’s a good article about this on CodeProject, and as usual, Chris O’Brien has been there and blogged about this too.

Anyway, working on my app I had a number of problems around deploying it, both for debug and ‘live’, in particular around the AppManifest.xml file.

I had built my remote event receiver, and it was working nicely in an F5 Deploy and using the Azure Service Bus (Point 6). It didn’t work in proper ‘Publish’. I had added the app to the catalog, and I had done the ‘AppRegNew’ bit (Point 2)

I had read that before deploying to live I would need to set the ClientId in this file (Point 5) from:

<AppPrincipal>
<RemoteWebApplication ClientId="*" />
</AppPrincipal>

To:

<AppPrincipal>
<RemoteWebApplication ClientId="deadbeef-cafe-babe-face-beadedfacade" />
</AppPrincipal>

This seemed to work and I was able to deploy the app – and it worked. Cool. So I started to work on it some more, but when I tried to debug it using an F5 Deploy and the Service Bus – well it didn’t work now.

Careful unwinding of the changes showed that the F5 Deploy and debug over the service bus started to fail when I changed the ClientId=”*” to contain the GUID. Weirdly, when I put the * back, F5 debugging started to work again.

Curiosity roused, I decided to compare the AppManifests from the packages for ‘works in debug’ and ‘works in publish’:

Anyway, this shows some interesting differences in the AppPrincipal section. For the published version, it’s as I’d defined above. But for the F5 deployed version the whole RemoteWebApplication node has been replaced with:

<AutoDeployedWebApplication>
<DebugInfo ClientSecret="3x9Ku5a3jYGzbbMsehJSP2kAW/Ufd0krSx+NZhS6Ccc=" AppUrl="https://localhost:44303/;https://awburns1.servicebus.windows.net/xxxxxxxxx/burnsaw/obj/9144fc70-1385-4cf9-b940-35c316625c31/" />
</AutoDeployedWebApplication>

Blimey. Okay, that’s a) clearly very different, and b) clearly about debugging, especially as it has the URLs to the localhost website that’s used for debugging the code, and the service bus itself.

So it seems that asterisk is kinda important. When moving between development and publishing, you’ll want to add or remove that * as appropriate.

Other changes I noticed were:

• The debug version app assigned itself a new ClientId; I’m not quite sure why it did that. This has also been put into Web.Config for the Azure website project.
• Although I’d found several posts that mentioned manually updating ~remoteAppUrl with the URL of your web service or service bus, it appears this is unnecessary. In both debug and publish it appears to have resolved this correctly. Obviously, you could set it to a particular web service – that’s part of the point – but in my case, I’m just using an Azure web site, much as Chris suggests. I’ll let Visual Studio handle it.

Other things that I had to do to make the app work:

• Make sure the ClientId and ClientSecret for the app are in the Azure settings; this seems to be necessary for a live publish of the web for the app (Point 8). It doesn’t seem to be necessary in debug, but I suspect that is because the service bus actually routes the call to the locally running website, and it’s web.config has been updated by with the new ClientId.
• Make sure you’ve Registered a New App (using /_layouts/15/appregnew.aspx) to register your app (Point 2)

Being able to debug the remote event receiver like that is absolutely fantastic – without it you’d be developing blind. Break points in Visual Studio are hit without any issues. And the service bus seems to be close to magic – it just works!

And, interesting, the performance of remote event receivers from Office 365 is considerably better than Sandboxed event receivers within Office 365 (at least in SharePoint Online 2010)