Azure Custom Domain Settings

It was a little confusing setting up my custom domain in my Azure settings for this blog. I’m no Network/DNSexpert and hardly know my CNAME from my MX from my A records. So when I was trying to figure it all out, needless to say, I was worried I was going to break the internet!! After a bit of trial and error I managed to get it working. Hopefully these tips will help you too if your having issues.

The first thing you need to do is to update your Azure Website Mode. This is found under the Scale menu. Azure Website Mode

Change the mode from FREE to SHARED (note this will mean you can incur costs depending on your Azure plan/account).Shared mode is still run in a shared environment (ie. memory, CPU etc..) but with less stringent monitoring than the free mode. If you want your own dedicated Virtual Machine etc… then choose standard mode.

Next you’ll need to configure your domain settings. Go back to the Azure Dashboard and scroll to the bottom of the screen. You will see the MANAGE DOMAINS item on the status bar:

Azure Dashboard

Click the MANAGE DOMAINS item to open the property sheet:

Azure Manage Domains

When you first come to this screen, you will only see your websites Azure URL. In this case it was: monkeysandgorillas.azurewebsites.net.

So you have to first create a DNS CNAME record with your hosting service that maps the full domain name (eg: www.monkeysandgorillas.com) to the monkeysandgorillas.azurewebsites.net domain. This is sometimes declared as the WWW record in the DNS settings. The specifics of how to do this are different for each hosting provider. You might need to google for yours.

It will take a bit of time for this first CNAME entry to propagate around the web. Once it has – it could take anywhere from 2-24hrs – you need to come back to your Azure Manage Domains settings and then enter your full domain name with the leading ‘www’. (eg: www.monkeysandgorillas.com). If you have set up your CNAME record correctly and Azure can resolve your full domain, you will see the green success tick, as shown above. If not, you will get a red circle with a cross in it.

Once you have the tick, you then need to go back to your hosting provider to add the A Record to your DNS settings. The A Record is often specified with the @ symbol in the DNS settings. This time though you will need to enter the IP address as shown in the Manage Domains property sheet. In my case I added the IP Address: 168.62.224.13. Save your DNS settings and then you will once again have to wait for the updates to propagate around the web.

Lastly you need to return to the Azure Domain Management interface and enter your domain name, without the leading ‘www’: (eg: monkeysandgorillas.com). Once again, if Azure can resolve the DNS record, you will see the success tick. Go ahead and click the save icon (the grey tick) in the bottom right hand corner of the property sheet.

Note: I tried to set the awverify.www.monkeysandgorillas.com in my DNS record and it just wouldn’t work. Even without it I managed to set the www & @ records which achieve what I was after. The instructions on the Manage Custom Domains screen do say you can set either the www or the awverify version of your domain. So I guess try one and if that fails try the other. But just remember you need to give it a bit of time to propagate each time you make a change.

For more information see:

https://www.windowsazure.com/en-us/develop/net/common-tasks/custom-dns-web-site/

 

Switching Hosting to WordPress on Azure

I’ve migrated this blog from being hosted on blogger.com across to WordPress and hosted it on the Microsoft Azure platform. (they’re even offering a free trial!) Pretty much everything went smoothly, but unfortunately in the switch I lost all the previous comments! My apologies for this.

For a great set up guide for WordPress on Azure, definitely checkout TekPubs brilliant guide to getting involved. Rob Conery and Scott Hanselman do an awesome job of covering all the things you need.

To see how to set up your custom domain settings in Azure I’ve written another post which covers this – Azure Custom Domain Settings.

EntitySpaces – Access Multiple Databases Dynamically

I’ve been using EntitySpaces ORM (http://entityspaces.net) for a number of years now in my consulting work. They recently (late 2012) shut up shop and open sourced the code. It was a bit of a shame, not to mention quite surprising, as I thought they were a great company with a great product. But I’m very grateful they open sourced the project and it’s available for download from cnet.com… the full product, with all the tools, bells and whistles! Awesome stuff.

I recently came across the problem of how to dynamically access multiple databases for an Admin app I was building. A customer has 5 different databases that the Admin user can access to create, update or delete certain records. There can be multiple users logged in at once and therefore we need each user’s current database choice to be independent of each other. But I had a problem.

Normally, you would simply store the database choice (eg: country) in the users session ready for access whenever you need to hit the database. EntitySpaces has a nice mechanism for doing this. They provide an IConnectionNameService interface:

You add the database name to your session, and then when you call the EntitySpaces code, it will invoke the GetName() method and retrieve it from the session again and dynamically set which connection string to use from your web.config file.

This will work just fine on one condition – your database access code is running in the ASP.NET session context! What if your code is running in a separate .dll that is included in the project and knows nothing about the web, or ASP.NET or HTTP etc…??

You could try some of the following options:

  1. Pass the database name around from the web context to the DAL code. This means muddying the code with extra parameters and somehow keeping track of user context and thread safety.
  2. Create some sort of alternate collection to track which user is needing to connect to each database. maybe a hashtable/dictionary for quick look up. Here you would need to link back to the lookup class from anywhere where the database was being called.
  3. Find another mechanism for storing the user context and hooking into the EntitySpaces provided IConnectionNameService interface.

Options 1 and 2 simply aren’t practical and would make the code simply too messy. Option 3 though, has potential and with a bit of lateral thinking will provide the best solution.

Given that we are running in a web context on the ASP.NET stack, we have access to the Web Security framework and if we have an authenticated user who has logged in with their email address as their username, for example, we can use the current security context on the current thread as a unique way of storing the name of the database we want to connect to.

If I’m logged into my website then security identity context is going to hold the following information (I’m using forms authentication):

You can see that the Identity holds my login username – in this case my email address. So we can use this as a system wide unique ‘key’ into some collection where we can store which database name we want.

  1. We need a data store that is going to be accessible when the web application first fires up.
  2. We need to be able to store a reference to it that will persist and still be around independent of the ASP.NET Session.
  3. It would be nice to have some thread safety mechanism to allow for synchronized access.

A very nice and handy solution that ticks these boxes is the AppStart Dictionary which is automatically available to all pages in the website. It has the added benefits of providing synchronized access with it’s Lock() and UnLock() methods. We could use the global cache, and this would work quite nicely, but it doesn’t have synchronized access, although it does provide fine grain control over the life of the objects stored in it.

In a WebPages Razor website you would setup your EntitySpaces connection in the _AppStart.cshtml page:

We pass in a reference to the AppState ready to be accessed when the DAL code comes looking for which connection string to use. Here is our implementation of the IConnectionNameService interface:

Now, all we have to do is store the database name in the AppState global dictionary when the user is about to request something from the database:

Our Identity.Name (ie.email address) should be the same here as when the IConnectionNameService interface implementation is called later in the DAL custom .dll. Using a drop down select box in the web interface, you can dynamically change the database to connect to with each request.

As long as you store the country in the AppState dictionary, the EntitySpaces framework will pick it up and dynamically set it correctly each time. Very nice!

ASP.NET Sessions

Did you know that if you don’t put anything into an ASP.NET session, it will generate a new one with EVERY page request!!???

Try it out for yourself…

  • Create a new MVC(3/4) Web App in Visual Studio.
  • Choose the Razor rendering engine
  • Add the following code to index.cshtml

Run the website and you will see that the Session ID is different every time you click back to, or refresh the index page!

At first I though this was because I wasn’t logged in. If I go to the Register.cshtml page and create a new account, and login with it, this behaviour still persists.

It’s only when you add something to the session that you see the same Session ID being reused.

Go to the About.cshtml page and add the following code:

Run the app again, and make a note of the Session ID on the index.cshtml page. Next click the About menu tab, and then go back to the Home tab. You will see that your Session has been persisted because you added today’s name into the collection.

Why does it work this way? I’m not really sure. If you have any ideas, I’d be happy to hear them.