Monday, October 5, 2015

O365 Dev Challenges - Part 7 - Publishing the App to Azure

I know have a fully functional application running from localhost. If I access the local host URL from another tenant (not the one where I registered the app) it works just fine. But I don’t want it sitting locally, as I decided upon project creation to host it as an Azure web site.
Fortunately, this last piece of the puzzle is the easiest one!

Publishing the application

Right click the project node in Visual Studio and pick Publish. The Connection screen should list the URL picked in the wizard upon project creation. Feel free to hit Validate Connection to make sure it’s working.

clip_image002

Before you hit the Publish button, copy the value in the Destination URL field, in my case http://pzlsamplemultitenancy.azurewebsites.net.

Fix the application manifest to reflect the update application URL

Go back to the application manifest in the Azure management portal and replace https://localhost:44300/ with the value copied for your Azure web site – and be sure to add a trailing slash. Replace the URL in both the SIGN-ON URL field and the REPLY URL field and click SAVE.

clip_image004

Testing the application

As the application is now stored in Azure and the manifest is updated all that remains is testing it.
Open up a browser window where you are logged into either the publishing or test tenant – or an anonymous one and navigate to your Azure web URL, http://pzlsamplemultitenancy.azurewebsites.net/UserInfo, consent to the application, and click Send Mail, and you should receive an e-mail from yourself.

Summary

Starting out with something pretty simple took me on a journey where I learned a bit more about how the OWIN libraries work and how resources are access in code with matching delegate permissions in Azure AD. It also took me into refactoring and patching the scaffolding injected in my project, which all in all was a good path. At least I now have enough tools to keep on creating O365 add-ins.

The Unified API has also been launched with a beta of v2 where you can use dynamic app consent, which is quite cool. Don't prompt the user to consent to an action before you actually need it. I'll probably wait until there is wizards and nuget packages to take me there, but the future is looking bright indeed!

My hope for the future is that the wizards and scaffolding gets even better, and are close to production ready. The easier it gets, the more add-ins people will make (I hope).

Hope this tutorial and hoop jumping helps someone else out there - and any bugs or mistakes in my code can only be attributed to my lack of understanding how it all fits together :-)