On Thursday 7th, Microsoft launched a new version of Windows Azure. The launch included a new management interface (to replace the old Silverlight one), Linux VMs and a new caching feature. One of the more interesting features however, is the new Azure Web Sites. Web Sites addresses the lacklustre deployment experience that plagued Azure, one of the problems that AppHarbor set out to solve.

We’re excited to see Microsoft adopt a deployment approach so similar to AppHarbor’s. Microsoft launching Azure Web Sites validates the approach to deploying .NET applications that we’ve been pioneering for the past year-and-a-half.

Are we worried about the Azure Web Sites launch? Not really: When building AppHarbor, we set out to build a better platform than Azure. With Web Sites, Azure got slightly better, but the situation is the same: We’re still committed to making AppHarbor the best place to deploy and host .NET applications in the cloud.

Looking at the Web Sites feature in greater detail, there are some interesting things to note:

• Azure Web Sites has no equivalent to AppHarbor background workers to handle background processing for your app.
• Azure Web Sites has no way to add your own SSL certificates at all. If your app needs SSL, you’re stuck with running on the Azure subdomain and piggy-backing off their certificate.
• Naked domains are not supported for sites running on Azure.
• You can only add custom hostnames to apps running on reserved instances, not to apps running on shared infrastructure.
• There’s no free database option that you can use for test- and staging-apps
• Microsoft announced a few external service providers at the launch (ClearDB MySQL and Cloudant), but Cloudant is not yet available in the interface and it’s at any rate a rather limited selection compared to our add-on catalog
• Unit tests are not run before your code is deployed to Web Sites, leading you to potentially push faulty code
• While Azure Web Sites have a free option during the test period, there’s no permanently free option like on AppHarbor.
• Azure Web Sites has no notion of several developers collaborating on an application.

Other than the slick and responsive user interface on the new Azure, we’re also rather impressed with the performance monitoring, logging and error reporting features built into Web Sites. On AppHarbor, you can get detailed logging and performance monitoring courtesy of New Relic, but we’re working on augmenting this with better built-in platform support.

The way we think about Azure Web Sites is summed up very well by Marco Arment when writing about Apple launching a service similar to Instapaper, a service he built:

My biggest challenge isn’t winning over converts from my competitors: it’s explaining what Instapaper does and convincing people that they actually need it. Once they “get it”, they love it, but explaining its value in one quick, easy-to-understand, general-audience sentence is more difficult than you might imagine.

Now that Microsoft has launched Web Sites, they’re going to spend tons of time and money educating .NET developers that the AppHarbor way of deploying and scaling .NET applications is the best one. This is great for us since more developers will want to use source-code based deployment services and we’re confident many will choose AppHarbor when they realise the limitations inherent in Azure Web Sites.

While Azure Web Sites is an improvement on the previous Azure deployment experience, we strongly feel that AppHarbor has lots of advantages, and we’ll work hard to make sure things stay that way. We look forward to welcoming lots of new developers, educated by Microsoft that source-code based deployments is the way to go, onto AppHarbor.

Starting today, you can provision SpreedlyCore to applications running on AppHarbor. SpreedlyCore is a payment gateway wrapper and it currently supports more than 25 gateways including Braintree, PayPal, Stripe, Ogone and SagePay. The two greatest advantages to using Spreedly are:

1. You can easily work with multiple gateways to optimize your users' experience and your transaction costs
2. You're not tied into any one gateway and can easily switch out ones you're not happy with

Spreedly has a free starter plan that's great for testing and a super slick API. Add SpreedlyCore to your app right now and start accepting payments through any of the 25+ gateways supported by Spreedly.

This post describes how to consistently track business events (sign-ups, sign-ins, purchases) using Google Analytics event tracking. Tracking events with Google Analytics greatly eases goal and funnel analysis and makes figuring out stuff like what traffic sources yield the most sign-ups easy. The sample code below uses the ASP.NET MVC framework, but the technique is applicable to web applications written in any framework.

Problem

Imagine you have a standard Google Analytics tracking setup:

<script type="text/javascript">
    var _gaq = _gaq || [];
    _gaq.push(['_setAccount', 'ACCOUNT-ID']);
    _gaq.push(['_trackPageview']);
    (function () {
        var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
        ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') +
            '.google-analytics.com/ga.js';
        var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
    })();
</script>

And imagine that and you want to do funnel analysis on visitors that sign up for your service. People seem to currently go about this in one of two ways:

1. Add a /thankyou.html page, send users there after sign-up and configure that as a "Goal URL" in Google Analytics
2. Add an onClick event handler to the form button that users click when signing up and call _trackEvent from the event handler

Neither of these options are attractive. Number 1 forces you to redirect users to a particular page to accurately track them even though redirecting to the front page and displaying a message might be a more natural flow. If you don’t send users to a particular page and redirect them to the front page after registering the sign up, you won’t be able to tell from Google Analytics whether the user arrived there on his own or after being redirected after signup.

Option number 2 is bad because clicking the sign-up button does not necessarily mean the visitor actually gets to sign up. If there's a validation error, the visitor will fill out and click the submit button again, registering an extra sign-up. If the user doesn't fix the validation error and gives up, a signup that never actually happened will be tracked in Google Analytics.

Solution

This problem is easily fixed: Simply track the event on the next page (whatever it is) before that page view itself is tracked. We’ll track events using the Google Analytics Event Tracking API. While nominally a client side api to track stuff like video plays and AJAX requests, we’re going to be using it to track server-side events by conditionally outputting Javascript calling the _trackEvent method:

_trackEvent(category, action, opt_label, opt_value, opt_noninteraction)

In the AppHarbor ASP.NET MVC codebase, we track server-side events using a TrackEvent method in our ControllerBase class:

protected void TrackEvent(string category, string action, string label = null,
    decimal? value = null, bool? nonInteraction = null)
{
    const string tempDataKey = "GoogleAnalyticsEvents";

    var intValue = Convert.ToInt32(value);

    var events = (List<GoogleAnalyticsEventViewModel>)TempData[tempDataKey]
        ?? new List<GoogleAnalyticsEventViewModel>();
    events.Add(new GoogleAnalyticsEventViewModel
    {
        Category = category,
        Action = action,
        Label = label,
        Value = intValue,
        NonInteraction = nonInteraction,
    });

    TempData[tempDataKey] = events;
}

The code above works with the CookieTempData provider mentioned in a previous blog post. TrackEvent is invoked from controllers:

if (ModelState.IsValid)
{
    TrackEvent("User", "UserCreated");

    SetSuccessMessage("Your account has been created");
}

The events are used to generate the required _trackEvent calls:

<script type="text/javascript">
    var _gaq = _gaq || [];
    _gaq.push(['_setAccount', 'ACCOUNT-ID']);

    @{
        var googleAnalyticsEvents =
            (List<GoogleAnalyticsEventViewModel>)TempData["GoogleAnalyticsEvents"];
    }

    @if (googleAnalyticsEvents != null) {
        foreach (var googleAnalyticsEvent in googleAnalyticsEvents) {
            var label = googleAnalyticsEvent.Label == null ? "undefined" :
                string.Format("'{0}'", Json.Encode(googleAnalyticsEvent.Label));
            var value = googleAnalyticsEvent.Value == null ? "undefined" :
                string.Format("{0}", googleAnalyticsEvent.Value);
            var nonInteraction = googleAnalyticsEvent.NonInteraction == null ? "false" :
                string.Format("{0}", googleAnalyticsEvent.NonInteraction).ToLower();

            @:_gaq.push(['_trackEvent', '@googleAnalyticsEvent.Category',
                '@googleAnalyticsEvent.Action', @Html.Raw(label), @value, @nonInteraction]);
        }
    }

    _gaq.push(['_trackPageview']);

    (function () {
        var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
        ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') +
            '.google-analytics.com/ga.js';
        var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
    })();
</script>

Note that events are tracked before the pageview of the current page itself is tracked with _gaq.push(['_trackPageview']);. This ensures correct sequencing of events and pageviews in Google Analytics.

The code outlined in this post uses ASP.NET MVC, but the technique is applicable to apps written in any decent web application framework.

The screenshot at the top of the post shows the signup goal flow for AppHarbor by traffic source. Information like this lets us figure out stuff like what traffic sources convert well to signups (and purchases) and effectively prioritize our marketing and outreach efforts. All thanks to accurate tracking of server side events with Google Analytics.

Today we're releasing a nifty project dubbed ConsolR. ConsolR is a console that you add to an ASP.NET web application to let you run arbitrary C# from within the app. This means that everything that's available to your application (or your application's AppDomain to be more precise), will be available from ConsolR as well. This allows you to execute code on-the-fly from a browser using C# in your application's environment, which is useful for numerous use cases.

The tool is mostly intended for debugging applications as it provides access to the application's state. It's also a convenient way to access a production server's dependencies such as external databases, caching and logging services, which may not always be accessible from the developer's own machine. All namespaces, classes and so forth that are available for your application can be called from ConsolR.

In this screenshot you can see an example of how ConsolR works when it is installed on an application that uses Entity Framework. On the left hand side a database context is initialized so we can loop over the users in the database. ConsolR uses SignalR to communicate with the web server, so we can use that channel to "log" messages back to the browser.

If you're familiar with Compilify by Justin Rusbatch you'll find that it works and looks pretty much the same. This is no coincidence. The entire project is based on Compilify and is essentially a stripped down and re-purposed version with fewer dependencies. On top of that some auto-registration of the required routes and http handlers happens when the application starts, so you don't have to do anything to wire it all up.

Installing ConsolR is really simple. We've packed everything up in a NuGet package, simply run Install-Package ConsolR to install it. ConsolR will register itself and be available under the "/consolr" path (default username/password is "foo"/"bar"). All of this is of course configurable. Make sure to add the new files in the /assets directory to your version control system and you're ready to go. If you have enabled NuGet package restore you don't need to include the ConsolR package and binaries.

ConsolR is designed to work with all types of .NET 4.0 web applications, including MVC, ASP.NET Web apps, Nancy projects etc.

The project is released under the MIT license and we're happy to accept contributions. ConsolR is an early alpha release and usage of it is your own risk. Read more about ConsolR and get the source code on the project page

NuGet 1.8 was released a few days ago. We have updated the AppHarbor build process to handle the new "Package Restore and Consent" setting and projects using NuGet 1.8 will work on AppHarbor out of the box. Our opinion of the consent requirement is accurately reflected by this comment.

On a more uplifting note, NuGet 1.8 also comes with a feature that can greatly speed up your AppHarbor builds if you're using NuGet package restore. This is because the new version downloads packages in parallel, making restoring packages up to 60% faster.

The safest way to upgrade a package-restore-enabled solution from a previous version of NuGet is to first remove the feature:

1. Open *.csproj files and remove <RestorePackages>true</RestorePackages> and <Import Project="$(SolutionDir)\.nuget\NuGet.targets" />
2. Remove the .nuget folder from the solution and from the file system

Now make sure that you have updated to NuGet 1.8 and then re-enable package restore. After committing the changes to NuGet.exe and NuGet.targets and pushing to AppHarbor, your builds will be run using NuGet 1.8 and will be much faster as a result. (Switching out the nuget.exe file for the new one should also work, but we haven't tested this).

Happy NuGet'ing!

A few days ago GitHub launched GitHub for Windows, a beautiful Windows Git client. The client is fast and easy to install, it has an attractive Metro-themed design and it lets you do most day-to-day Git operations such as checking out, branching and committing with ease. Git has always been our favorite source control management system, and we love this new way to manage our repositories. Some .NET can be a bit spooked by the console-heavy interface of standard Git, and at AppHarbor we hope GitHub for Windows will make using Git easier for those folks.

Using GitHub for Windows to deploy to AppHarbor is very simple. Assume we have already installed GitHub for Windows and hooked it up with our GitHub account and say we want to deploy a new application. First, create the repository using GitHub for Windows:

Make a note of where the repository was created on your file system and create an application in Visual Studio using that location:

Go back to GitHub for Windows and commit the newly created project:

Go to appharbor.com and create a new application to run your project. Head over to GitHub and configure the AppHarbor service hook as you usually would. Now hit "Publish" in GitHub for Windows to send your code on its way.

GitHub for Windows will push your code to GitHub which will notify AppHarbor of the new commit. AppHarbor will then download the code from GitHub and build, test and deploy it.

Et Voilà: Deploy to AppHarbor using Git without ever opening a console!

This Screencast walks you through setting up an ASP.NET MVC web application backed by Entity Framework Code First. Entity Framework is configured to automatically upgrade the database schema when the application model is updated whether the database is a local SQL Server Compact Edition or a full SQL Server hosted on AppHarbor.

Resources

• Source code on Github
• Blog post walkthrough
• Video on YouTube

We know a lot of you have been waiting for this: You can now create AppHarbor applications in the EU! This new feature will make creating fast and responsive apps targeted at European end users a lot easier. EU applications will still run on Amazon's high performance infrastructure, only they'll be running out of the EU-West region (Dublin) instead of US-East, where all current applications are located.

We have spent a lot of time making sure the AppHarbor platform is modular and scalable and this paid dividends when time came to spin up our new EU location. New applications are created in either the US or EU and existing applications cannot be moved, but we're already thinking about how to turn this up another notch to make AppHarbor a zero-configuration, multi-region, geo-load-balanced application platform.

Add-ons in the the AppHarbor add-on catalog will work with EU-based applications. Some (such as SQL Server) will intelligently provision resources based on where your application is located. We're working with our other add-on providers so that latency-sensitive add-ons can be provisioned in locations close to the application that is going to consume the add-on. For add-ons that do not currently support the EU, a warning will be displayed when they're provisioned to an EU application.

We're incredibly excited about this feature and we can't to see all the great apps that will soon be running out of the new AppHarbor EU location.

Image credit: Håkan Dahlström

We're very excited to welcome Xeround into the AppHarbor add-on catalog. Xeround is a cloud database, engineered from the ground up to be elastic, scalable and resilient to hardware failures. Xeround is MySQL-compatible and this lets you take advantage of all the great MySQL drivers and other tooling out there and not worry about learning new APIs or tools. The Xeround homepage has more details on what makes the service tick.

Using Xeround from your AppHarbor-hosted application is as simple as adding the add-on and then using the injected connectionstring in your app. We've written a short guide on using Xeround and we also provide a complete ASP.NET MVC sample application that you can either use to get started or look at for inspiration. It uses NHibernate and SchemaUpdate for easy configuration and hands-free automatic migrations.

Don't miss out on a great service, add the Xeround add-on) to your AppHarbor app right now.

We’ve recently made two significant improvements to the AppHarbor build setup: ASP.NET view precompilation and more and bigger build servers. Read on for details on both.

ASP.NET view precompilation

We recently extended support for ASP.NET view precompilation. Previously, if an application project file specified view precompilation AppHarbor would build application views but view build-output was not included in the package that AppHarbor deploys. View compilation on AppHarbor gave the safety of knowing that views contain no syntax errors, but it did not improve application startup performance.

We have now changed our build handling to package the view build output with the rest of the app. For new apps, compiling views is on by default (you can toggle this in application settings). Properly precompiled views should make your app start much faster.

View precompilation on AppHarbor is a separate step from the rest of the build so if your project file specifies MvcBuildViews and view compilation is specified for the app, views will get built twice. For that reason, we recommend setting MvcBuildViews to false for apps you’re deploying to AppHarbor.

Faster build servers

AppHarbor has grown significantly over the past year. If you’ve noticed increased build times it’s because our build infrastructure has been increasingly strained. In fact, until a few weeks ago, all builds were processed by a single server processing builds in sequence and it was beginning to show.

We launched AppHarbor with the promise to "deploy in 15 seconds, not 15 minutes". To stay true to that promise, we've now improved our build setup so that it can handle multiple builds simultaneously. We have also added additional and bigger build-servers and the built-in Git service runs on its own instance. This has the following advantages:

• Builds will rarely be queued for more than 3-5 seconds.
• Compilation is much faster (up to 60-70%) than on the old server
• The complimentary Git service is more reliable

The old build- and git-server is the oldest EC2 instance in the AppHarbor lineup and it's been with us since the very beginning when we had no money to buy fast instances. It previously hosted Git-repositories, ran builds and unit tests and held all AppHarbor SQL Server databases. It’ll soldier on for a time, running the Git-repositories that come with each application. But rest assured that it’s no longer slowing down your AppHarbor deploys.

We'll continue to optimize build times and improve application startup performance. We are also looking forward to new features in .NET 4.5 that'll let us further improve these aspects of AppHarbor. Until then we hope you'll enjoy the improved build process and give us any feedback you may have about how we can make it even better.

Image credit: Ciprian Popescu