Publishing to Azure Web Sites from any git/hg repo

Windows Azure Web Sites provide a nice selection of ways to deploy a site from source code. You can deploy from:

• a local git repository
• a TFS project
• a git project on GitHub
• a git or Mercurial project on Bitbucket
• a git or Mercurial project on CodePlex
• code in a Dropbox folder

One thing that all these approaches have in common is that you own the code. e.g. in the GitHub case, you must be an admin on the project. The reason is that Azure needs to set up a hook in the project to enable continuous deployment, and only project owners can do that.

 

Deploying ‘external’ repositories you don’t own

In some scenarios, it can be interesting to deploy a site based on sources that you don’t own. For example, you might want to deploy your own instance of the NuGet gallery, but you have no intention to modify the source. You’re happy with it as is, and you just want to deploy it.

To cater to this scenario, we added a new ‘External repository’ entry in the Azure portal:

Note: the ‘External repository’ entry is using the git icon, which is technically incorrect since it supports both git and Mercurial. We just didn’t have time to come up with a better icon for it for this initial release! We’ll probably change that later.

Once you pick that, the next page in the wizard is pretty simple: you just paste any http(s) git or Mercurial URL and you’re good to go!

And as soon as you Ok the dialog, a deployment from that repository gets triggered.

 

What about updates?

One important point about this mode is that it doesn’t support continuous deployment. This is because Azure cannot possibly register for change notifications on an arbitrary repo that you don’t own.

Concretely, that means that your site will not be automatically deployed when the repo is updated. Instead, you need to tell it when you want to pick up changes, by clicking the Sync button in the Deployments page:

While this feature may not see the same kind of usage as the full continuous deployment workflows, it has its uses and nicely completes the overall source deployment story in Azure Web Sites.

Managing database connections in Azure Web Sites

This topic is not specific to git publishing, but it’s particularly useful in that scenario

In its first release, the Azure portal had a couple of limitations relating to database connections:

• The database name had to match the connection string, which was quirky
• You could not add external connection strings

The good news is that both limitations have now been removed, as you’ll see here.

 

Using a SQL Azure database associated with the site

Let’s say you’d like to publish the awesome NuGet Gallery to an Azure Web Site. When you create the site in Azure, choose the ‘Create with database’ option:

You will see a dialog that looks like this:

Let’s assume that you don’t have a database yet, and you’d like one to be created for you. All you have to do here is give Azure your connection string name (highlighted above).

So where does this ‘NuGetGallery’ string come from? It’s simply the name of the connection string from the app’s web.config:

This way, you don’t need to change your sources to point to the SQL Azure database. You instead rely on Azure to use the right connection string at runtime.

After the following step, you can complete the wizard by either creating a new DB Server or use an existing one. Note that the database itself can be named anything you like (or keep the random name), since it is now decoupled from the connection string name.

At this point, you can just ‘git push azure master’ the NuGet Gallery sources, and your site is up and running with no further configuration!

Now if you go into the Configure tab for your site, you’ll see your associated connection string:

Note that it’s hidden by default, but you can choose to display it if you need it (e.g. if you want to connect via SQL management studio). You can even edit it if you want to tweak it!

 

Working with external connection strings

In the scenario above, we were using a database that Azure created for us along with the site. In some cases, you will instead need to work with an existing database, which may or may not be hosted on Azure.

In that scenario, you’d create your site without any databases. Instead, you can manually add the connection string in the Configure tab, e.g.

Note: don’t forget to click the Save button at the bottom of the page when you’re done!

Note that as before, we’re naming the connection string after the one in web.config. The only difference is that the value now comes from you instead of coming from Azure.

Using a naked domain with a Windows Azure Web Site

 

Update (9/17/2012): as of today, Azure Web Sites have direct support for A record, so the hack below is no longer necessary!

 

Warning: the following is just something that worked for me, and that others asked me about. It is not a Microsoft approved technique, and it could cause your cat to self-combust with no warning. I’m just a guy trying random things here.

 

Windows Azure Web Sites (WAWS) support custom domain names, as documented on this page. This makes it easy to use a name like www.davidebbo.com, by setting up a CNAME record in your DNS.

But a lot of people are asking how to make the name just davidebbo.com, which is known as a naked domain (aka a bare or root domain). Normally, this is done by setting up an A record, but this requires a stable IP address, which is not currently available in WAWS.

But it turns out that you can use use a CNAME for the naked domain, even though many people say it’s a bad idea (more on this below).

I’m not sure if this works with all registrars, but I use NameCheap, and it works with them. Here is what it looks like in the NameCheap DNS records:

So I’m doing two things here:

• First I’m making http://davidebbo.com go to my WAWS
• Then I’m making http://www.davidebbo.com redirect to http://davidebbo.com/. This is optional.

Then I have the following in the Configure tab of my WAWS:

Though really, I only need the last entry since I’m redirecting www to the naked domain. I just left the www entry in there because it doesn’t hurt. The first one could go too.

 

So what’s wrong with doing this?

If you search around, you’ll find a number of pages telling you that it’s unsupported, and breaks RFC1034 (e.g. see this page). And I’m sure that the experts will crucify me and call me an idiot for blogging this, but heck, I can live with that!

Personally, I don’t care so much about breaking an RFC, as much as I care about breaking my award winning http://davidebbo.com/ web site, which brings me most of my income.

So what might break? From what I’m told, doing this breaks MX records, which matters if you’re running an email server under your host name. So if I wanted to be me@davidebbo.com, I probably couldn’t. But I don’t, so I don’t care. It might also affect other types of records that I’m not using.

All I can say is that so far, I’m yet to find something broken about it, and I’ve heard from several others that they’ve been using this successfully for a while (not with WAWS, but that shouldn’t matter).

Anyway, I think you get my point: try at your own risk! And sorry about your cat.

Developing Kudu locally and on Azure

A few days ago, I discussed how the git support in Azure Web Sites was written as an Open Source project called Kudu. This time, I’ll give a few more details on how to run it, both locally and on Azure.

To be clear, you don’t have to care about any of this if you just want to use git deployment to Azure. Just use it as is and it should work great!

This is for folks who are interested in modifying the git deployment engine itself, either to contribute some changes to the project, or just to play around with things.

Running Kudu locally

First, you can see it all in action in this 3 minute screencast!

Here are the basic steps to run Kudu locally. Note that this requires using IIS7, and will not work with IIS Express.

• Clone it from https://github.com/projectkudu/kudu.git
• In Visual Studio, open Kudu.sln. Important: VS needs to run as administrator!
• Set Kudu.Web as the Startup solution
• Ctrl-F5 to run
• You’ll get an admin page that lets you create sites, and gives you the git URL for them
• Try git pushing a test project, and see it run!

Important note: the primary purpose of running Kudu locally is to make it easier to develop outside of Azure. Conceivably, you can take this non-Azure Kudu and host it on a VM, to have your own mini deployment server. However, it’s missing a few features that would make it really usable there. e.g. it doesn’t set up host names, and doesn’t set up authentication. We would love to add these features, and welcome contributions!

Running a private Kudu build on Azure

First, see it in action in this 5 minute screencast.

This is the more crazy one. Suppose you want to make changes to the Kudu service, and make it even more awesome. :) You can make these changes locally and test them outside of Azure, per the previous section.

But wouldn’t it be great if you could actually use your latest Kudu bits in Azure itself? Turns out you can, using a special hook that we put in for the exact purpose.

Here are the basic steps:

• As above, clone Kudu from https://github.com/projectkudu/kudu.git
• Make whatever changes you want to the sources
• Run build.cmd at the root of the repo. This creates an artifacts\debug\KuduService folder than contains the built Kudu bits.
• Go to the Azure portal and create a new app, then enable git.
• Use FTP to connect to your files, and copy the KuduService folder at the root. Here is what the file structure looks like in there.
• In the Portal, go to the Configure tab, and add an ‘app setting’ with name/value USE_PRIVATE_KUDU=1 (and don’t forget to hit Save at the bottom!).

And you’re done! If you now do a git push to your Azure site, you are now using your very own git engine instead of the one that comes with Azure. How cool is that? :)

Important notes:

• Doing this only affects this one site. If you have multiple sites where you want to use your private Kudu bits, you’ll need to set up each of them the same way.
• It probably goes without saying, but once you are running your own git deployment engine, you’re in unsupported territory, so don’t call product support if something doesn’t work! However, the Kudu team will always be happy to talk to you on JabbR, or our MSDN forum, or on github. :)

Introducing Kudu: the Open Source engine behind ‘git push azure master’

Yesterday, ScottGu unveiled the new Azure, which brings a whole list of exciting changes to the platform.

One of the most exciting new features is the ability to deploy Web Sites to Azure using git. Scott’s post covers that, and I also did a screencast on that topic.

One part that has not yet been discussed is that the engine that powers this feature was developed as an Open Source project from the first line. The project is code named Kudu and can be found at https://github.com/projectkudu/kudu. Kudu is a member of the the Outercurve Foundation, and is released under the Apache License 2.0 (the same as NuGet).

This project is actually not tied to Azure, and can run standalone on any machine. In that mode, you can push project and have them run in your local IIS.

So why is this project interesting to you?

There are a few reasons that you may be interested in this project.

The first is that it’s a good place to file bugs that you run into when you git push your project to Azure. You can also use our forum to discuss things.

The second reason is that the associated wiki contains lots of useful info about it. Well, at this time there isn’t all that much there, but the idea is that we’ll grow it as we go forward. And of course, wiki contributions are welcome!

And finally, you may be interested in contributing to the project, as we do accept contributions!

T4MVC has its own home, with some git love

I have just moved T4MVC to a new CodePlex project, instead of it being part of the MvcContrib project. Its new home is https://t4mvc.codeplex.com/.

If you’re a T4MVC user, that should not make much difference except that there is now a new place to discuss it and file bugs. NuGet is still the place to go to get T4MVC!

Note that T4MVC is still part of the MvcContrib effort, even if it doesn’t share the same source tree. Here are the reasons for the move.

Reduce confusion

T4MVC is quite separate from the rest of MvcContrib, because it’s just a T4 template, and not some code that’s part of an assembly. Having the T4MVC files be in their own little island in the middle of a repo with many unrelated thing has been a bit of a barrier of entry for people wanting to make a quite contribution.

Also, since all MvcContrib bugs are files in the same place, there was always additional pain for me to filter T4MVC issues from unrelated ones.

Likewise, we’ll now have our own discussion forum that only focuses on T4MVC. Most users have been using StackOverflow for T4MVC support, and you can continue to do that if you prefer.

Switch to git!

I’ve been increasingly using git over Mercurial (like everyone else it seems!), to the point where having to use Mercurial is becoming an annoyance. Since CodePlex now supports git, it was the perfect opportunity to switch to that!

Quick fun with Mono’s CSharp compiler as a service

Mono comes with a really cool CSharp compiler as a service. The only problem is that no one seems to know about it!

I think the main reason for this is that anything related to Mono causes a fair bit of confusion to all the people who are not familiar with it. And that certainly includes myself, as I know very little about it besides what I’m discussing in this post!

Talking to various people, the general misconceptions are:

• Mono only runs on Linux
• Even if it runs on Windows, it doesn’t use the CLR, so I can’t use it
• Mono is for strange people :)

And while that may be true for some aspects of Mono, it certainly isn’t for Mono.CSharp.dll. In fact, it’s a totally ‘normal’ library that you can use in your very ‘normal’ C# projects in Visual Studio.

The next hurdle is that it’s not all that easy to just get Mono.CSharp.dll. You have to either install an 80MB setup from here, or get a big .tar.gz file with lots of other things from here. And a lot of people on Windows don’t like dealing with tar.gz files (hint: use 7zip).

Now the good news: after chatting with Miguel de Icaza on Twitter, I put Mono.CSharp.dll on NuGet, making it totally trivial to use from VS. There goes that hurdle. (note: I’m the package owner for now, until some Miguel-blessed dev claims it).

Try Mono.CSharp in under 5 minutes

Just open VS and create a Console app, and add a NuGet package reference to Mono.CSharp. That takes a whole 30 seconds. And I’ll re-emphasize that there is nothing ‘Mono’ about this Console app. It’s just plain vanilla.

Now write some basic code to use the compiler. It all revolves around the Evaluator class. Here is the sample code I used (GitHub). It’s quick and dirty with poor error handling, as the focus is to just demonstrate the basic calls that make things work:

using System;
using System.IO;
using Mono.CSharp;

namespace MonoCompilerDemo
{
    public interface IFoo { string Bar(string s); }

    class Program
    {
        static void Main(string[] args)
        {
            var evaluator = new Evaluator(
                new CompilerSettings(),
                new Report(new ConsoleReportPrinter()));

            // Make it reference our own assembly so it can use IFoo
            evaluator.ReferenceAssembly(typeof(IFoo).Assembly);

            // Feed it some code
            evaluator.Compile(
                @"
    public class Foo : MonoCompilerDemo.IFoo
    {
        public string Bar(string s) { return s.ToUpper(); }
    }");

            for (; ; )
            {
                string line = Console.ReadLine();
                if (line == null) break;

                object result;
                bool result_set;
                evaluator.Evaluate(line, out result, out result_set);
                if (result_set) Console.WriteLine(result);
            }
        }
    }
}

It feeds it some starter code and start a REPL look to evaluate expressions. e.g. run it and try this. You type the first two, and the 3rd is output:

MonoCompilerDemo.IFoo foo = new Foo();
foo.Bar("Hello Mono.CSharp");
HELLO MONO.CSHARP

You get the idea!

What about Roslyn?

I blogged a few months back about using Roslyn to implement an MVC Razor view engine. I’m far from a Roslyn expert, and frankly haven’t done much with it since that post. From what I read, Roslyn has the potential to enable some very compelling scenarios in the future.

But there is one major argument right now in favor of using the Mono compiler: it’s pretty much feature complete today, while Roslyn is not even close. Totally understandable given that it’s a CTP, and is only meant to give an early taste of the feature.

So anyway, I still know close to nothing about Mono, but if I need to dynamically compile some pieces of C# in a ‘normal’ non-Mono project, I know that Mono.CSharp is not far away!