Google Glass Mirror.net on Azure

You may have been playing with mirror.net from Google’s developer kit for Glass on your local machine and are now wondering, how do I take my project from a local deployment to a real cloud backend, such as Azure? The following post is a step by step guide at getting started with the mirror.net example project, fixing some bugs and setting up all the pre-requisites to run it successfully on both locally as well as on Azure.

This guide is based on the following pre-requisites:

  • A Google account that is Glass enabled (you got an invite for Glass and purchased the device)
  • Registered your Azure Web Site’s URL for OAUTH 2.0 with Google’s API console
  • Visual Studio 2012 or later
  • Web Deploy 3.5
  • Checked out the mirror.net project using Git
  • You have an MSDN Account with access to Azure’s dashboard
  • An ASP.NET 4.5 Web Site instance on Azure
  • An SQL Database instance on Azure for your project

First off, when you check-out the mirror.net example (I’m assuming you’re familiar with GIT), you may have realized that some of the NuGet packages referenced are outdated. Update the project to .net 4.5 and then you can safely update all packages to the latest version, including the EntityFramework to version 6.

Setting up your Azure deployment

Models\Config.cs:

Make sure your redirect URI is set to your Azure instance over HTTPS (unencrypted HTTP won’t work for OAUTH 2.0):

After updating, you need to make a couple changes in your project:

\web.config (root of project)

Remove the <entityFramework> element and its parent, <defaultConnectionFactory>.

Now, go to your Azure Dashboard and set up an AzureSQL instance. Then click on “Show connection strings” to copy the ADO.NET connection string.

Add the following two lines in <connectionStrings> using the values from the ADO.NET string. The credentials are saved in their own, separate DB store (as configured by the project):

1
<add name=“StoredCredentialsDBContext” providerName=“System.Data.SqlClient” connectionString=“Server=tcp:<servername>.database.windows.net,1433;Database=<DBName>;User ID=<dbuser>@<servername>;Password=<dbuserpassword>;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;” />

If you want to connect to the SQL instance from your local network, you should also go to “Manage allowed IP addresses” to let your dev boxes public IP through to the instance.

The publish tool in Visual Studio 2012

The publish tool in Visual Studio 2012

If you want to use both connection strings for the Azure backend as well as for a LocalDB, Visual Studio’s publishing tool can help you with switching between one connection string to the other.

Local Database for testing on a development web server

Alternatively, for a localDB deployment to the locally on your machine without using a SQL backend, you can keep the following strings. Then, when you publish, you can use the Publishing Wizard to select the ADO.NET configuration for Azure and have the tool replace the connection strings in web.config for you, before it gets uploaded to the Azure backend. Please also note that LocalDB won’t work on the Azure backend for several reasons. Be aware that using the localDB requires a change in your local IIS web server’s global configuration, as listed below:

Edit %WINDIR%\System32\InetSrv\Config\applicationHost.config, and restart the service afterwards:

Troubleshooting settings

Add to <system.web> to make debugging easier (don’t do this on production sites):

Changes to the project files and bug fixes

Global.asax.cs:

Remove this line, as we are now setting the connection through web.config:

Controllers\AuthController.cs:

Fixes a bug where some callbacks won’t work.

Views\Main\Index.cshtml (fixed in master branch as of 2/18/2013):

Fix a bug in the delete post form (line 51):

From your Azure dashboard, export your publishing settings and import them to your VS project, by right clicking your project in your solution explorer and choosing “Publish”. Use these settings to deploy your web app.

Remote debugging

If you want to do remote debugging, remember that you should publish the “debug” version of your web app when uploading the project. Also ensure that you’ve enabled the Remote debugging setting in your Azure Dashboard for the Web site. The setting automatically expires after 48h and you’ll have to re-enable it for Visual Studio to be able to attach, so if you come back from a weekend and find yourself unable to debug, that is likely the problem.

Hope the above instructions helped you getting your project started. I’m excited to see what projects will be emerging in this space!

Finally…

I’d like to thank my friend and colleague Avneesh Sud for his help in getting these instructions together and I hope the above instructions have helped you getting your project started. I’m excited to see all the new projects emerging in this space!