Azure

Mapping naked domains and www. domains to Azure web apps

Azure web apps can be mapped to multiple domains, as well as naked domains.

To do this, you will need access to your domain name’s DNS settings.

Go Naked

A naked domain is the domain without the “www.” that you often see on websites. There are various reasons for using a naked url, that I won’t go into in this post.

Jump into your domain name’s DNS settings. Create a CNAME entry for awverify.yourwebsite.com, and point it to your azure domain (e.g. awverify.yourwebsite.azurewebsites.net). This tells azure that you are the owner of the domain.

Now, go into your Azure control panel and locate your web app.

Select “Buy Domains” and then “Bring External Domains”:

You will then be shown a dialogue on the right with a text box where you can enter you naked domain name (e.g. yoursite.com – no www):

After you enter the naked domain, azure will load for a minute whilst is checks for your awverify CNAME dns entry.

Once verified, you can then point your actual domain to your Azure website.

Note: You can use a CNAME or an A record DNS entry to resolve the naked domain of your site. Both methods are listed below:

Method 1. Using an A record DNS entry pointed to the IP shown in the azure portal

Once verified, you Azure will reveal an IP address. This should show up just below the text box where you entered the domain name. If it doesn’t show, wait a few minutes and refresh the entire page. The IP address should then be displayed.

Head over to your DNS settings and enter an a record for “*”resolving to your ip address listed in Azure. You should now have a working naked domain name.

Method 2. Using a CNAME DNS entry pointed to the azure alias

Head over to your DNS settings and enter a CNAME record for “*” resolving to yourwebsite.azurewebsites.net. You should now have a working naked domain name.

The merits of using an A record vs a CNAME entry are not something that I will go into in this post. You can read more about the two DNS entry types here.

Pointing a www. to your azure application as well (or any other subdomain)

As well as having a naked domain work, you will probably also want your www to work as well. This can be done using the same methods above, but crucially you will need to tell Azure that you also have ownership of the subdomain as well:

e.g. In order to verify www.yourwebiste.com, you need to create a CNAME dns entry for awverify.www.yourwebsite.com that resolves to awverify.yourwebiste.azurewebsites.net

In order to verify blog.yourwebiste.com, you need to create a CNAME dns entry for awverify.blog.yourwebsite.com that resolves to awverify.yourwebiste.azurewebsites.net

Again, once verified, you are free to setup and A record or CNAME record DNS entry to point to your Azure Web App.

 

Azure

Hosting multiple websites inside an azure app service

This information is up to date as of November 2015. The Azure offer changes a lot, so this information may become quickly out of date.

A few years back, Scott Hanselman wrote a blog post on how you could utilize the “Standard” tier of Azure websites to save money by hosting multiple sites. Well, that was back in 2013 and the azure offer has significantly changed.

Firstly, Azure Websites has now been merged under Azure App Service, along with a few other services. Here is a 5 minute video from channel 9 explaining what exactly is in Azure App Services.

So, how do I get that “Shared” tier multiple websites setup that Scott Hanselman originally blogged about? Well, the Azure App Service pricing details page looks like you can get there with the “Basic” tier, which is cheaper than “Standard”:

azure-app-service-pricing-nov-2105
Azure App Service offer. Screenshot grabbed in November 2015

And how do I actually set this up in my Azure portal?

Confusingly, what is priced as an Azure App Service basically means everything under the “Web + Mobile” under the “new” option in the azure portal:

azure-portal-Web-Mobile

Why? Because:

An App Service plan is the container for your app. The App Service plan settings will determine the location, features, cost and compute resources associated with your app.

More info here.

You get told this information when setting up your app service plan and location (not sure why it defaults to Brazil…)

azure-portal-app-service-plan

So, an App Service Plan is basically the billable container for your apps.

So if you want to create a new web app under the same App Service, simply select it when setting up a new Web App.

Azure, MVC, MVC 3, MVC4, Technical

Redirecting legacy pages in asp.net

Picture this situation.

An old (legacy) application has landed on your project pile. It is largely built in php, and you intend on re-writing it in asp.net MVC.

You will therefore need to somehow inform any parties that may be trying to access the old urls ending in .php, that the resource they are looking for has moved permanently. You may also wish to do this for SEO reasons.

This is something that cannot be achieved easily through routing; by default, IIS will not pass requests for resources ending in .php to your application. Your routing will therefore never be put to use for resources ending with .php.

The nicest solution I found to this issue is to setup a list of redirects within the system.Webserver section of your web.config file. The following listing below will send a HTTP Response status of 301 (Moved Permanently) for any requests for index.php and for prices.php:

<system.webServer>
 <httpRedirect enabled ="true" httpResponseStatus="Permanent" exactDestination="true">
 <add wildcard="/prices.php" destination="/prices"/>
 <add wildcard="/index.php" destination="/"/>
 </httpRedirect>
</system.webServer>

Index.php will now redirect to /, and prices.php will now redirect to /prices.

This code is currently running in the wild on Azure.

If you are unsure if you need a Permanent redirect or not, have a read of this article from Google.

Azure, Entity Framework, SQL Server

Drop all tables in a SQL Server database (Azure Friendly!)

Most online solutions to this problem will point you in the direction of the undocumented stored procedure, “sp_MSforeachtable“. This stored procedure takes in a string of SQL as a parameter, and will execute this string for each non system table in your database.

Here’s the problem: undocumented stored procedures suck. Their usage has been determined by reverse engineering. They are not officially supported. Their implementation and usage could change with updates and new versions, or could disappear totally.

Here’s something that illustrates my point: “sp_MSforeachtable” does not exist in SQL Azure. So, if your development environment is SQL Server 2008 but your production environment is SQL azure and you are using “sp_MSforeachtable“, you will get problems when you go live, which sucks.

Below is a simple, Azure and Entity Framework friendly bit of SQL that will drop all tables in your database, with the exception of your entity framework migration history table – “__MigrationHistory“:


while(exists(select 1 from INFORMATION_SCHEMA.TABLES where TABLE_NAME != '__MigrationHistory'))
begin
 declare @sql nvarchar(2000)
 SELECT TOP 1 @sql=('DROP TABLE ' + TABLE_SCHEMA + '.[' + TABLE_NAME
 + ']')
 FROM INFORMATION_SCHEMA.TABLES
 WHERE TABLE_NAME != '__MigrationHistory'
exec (@sql)
 PRINT @sql
end

 

If you need to drop your table constraints first, the following code will allow you to do so:


while(exists(select 1 from INFORMATION_SCHEMA.TABLE_CONSTRAINTS where CONSTRAINT_TYPE='FOREIGN KEY'))
begin
 declare @sql nvarchar(2000)
 SELECT TOP 1 @sql=('ALTER TABLE ' + TABLE_SCHEMA + '.[' + TABLE_NAME
 + '] DROP CONSTRAINT [' + CONSTRAINT_NAME + ']')
 FROM information_schema.table_constraints
 WHERE CONSTRAINT_TYPE = 'FOREIGN KEY'
 exec (@sql)
 PRINT @sql
end

Credit to SQL Server Central for the above snippet.