You've clamoured for it and now you have it: Hosted RavenDB is in beta as an add-on on AppHarbor. The add-on is built by the the crew at RavenHQ and the team includes Ayende Rahien who built RavenDB originally.

RavenDB is a fast and scalable document database built on .NET. It comes with powerful querying facilities for fetching data to be used by applications running on the .NET platform. The client library is easily fetched from NuGet using this command:

Install-Package RavenDB

The RavenDB website has a great guide on how to use RavenDB in ASP.NET MVC applications to get you started. We have put a sample MVC app that uses RavenHQ for storage. Note that the AppHarbor will insert your RavenDB connectionstring in the connectionStrings element with the name "RavenDB". Please note that the DocumentStore configuration is slightly elaborate. This is due to a bug in the RavenDB client. A pull request has been submitted.

RavenHQ is hosted in the cloud on Amazon Web Services and runs out of the US-East datacenter -- the same one as your AppHarbor applications. This gives you ultra-low-latency RavenDB access from any application hosted on AppHarbor. Note that RavenHQ is currently available exclusively through the AppHarbor add-on catalog!

We're incredibly excited to have RavenHQ as an AppHarbor add-on, and we can't wait to see all the awesome apps you guys will build using AppHarbor, RavenDB and the other great add-ons in the add-on catalog.

Today, we're excited to welcome MongoLab in the AppHarbor add-on catalog. The MongoLab crew has been running a fast and stable hosted MongoDB service for a while and AppHarbor users now have easy access to provisioning databases on MongoLab. You can connect to your MongoLab database using any of the standard .NET drivers and MongoLab comes with a web interface that lets you add indices and query and edit your data with ease. We have a brief knowledge base article on how to use Mongo from your AppHarbor application and there is also a complete ASP.NET MVC sample app on Github. MongoLab monitors servers 24x7 and databases are backed up daily.

For-pay plans start at $10/month and a free 240MB MongoDB database is available for development and testing. To learn more and to sign up go here: https://appharbor.com/addons/mongolab. Also check out this detailed guide on the MongoLab blog.

Even though we've been in business for only slightly more than a year, AppHarbor is already occupying our fifth Bay Area office in succession (and no: we were not kicked out of the previous ones for bad behavior if that's what you were thinking). We hope to stay at our present location a little longer and we would like to invite all our Bay Area friends over for an office housewarming this coming Friday, February 17th. We will also be celebrating the end of the AppHarbor Copenhagen's team week-long visit to San Francisco. It's been an awesome week of late night hacking sessions, riding the Ballmer Peak and making AppHarbor even better. New versions of appharbor.com were deployed 14 times today (Wednesday) alone, and were not done yet!

Our new office is at 500 3rd st. (on Bryant), suite 210 in SOMA. We will have drinks and snacks ready from 5pm. Drop by and meet our Copenhagen team and help us get settled in our new office!

NuGet 1.6 shipped with a great feature called NuGet Package Restore. This feature lets you use NuGet packages without adding them to your source code repository. When your solution is built by Visual Studio (or MSBuild), a build target calls nuget.exe to make sure any missing packages are automatically fetched and installed before the code is compiled. This lets you keep your repository small by keeping bulky packages out of version control.

To use NuGet Package Restore with AppHarbor, open your favourite AppHarbor hosted app in Visual Studio, right-click the solution icon and select "Enable NuGet Package Restore". Add the "packages" directory to your .gitignore file and untrack the packages directory if it's already added to your repository:

git rm -r --cached packages

Now you can push to AppHarbor (or GitHub, Bitbucket or CodePlex if that's where your code is hosted) and the packages folder will automatically be re-populated with the NuGet packages your solution requires to successfully build. You can verify that this happens by looking at the build output on AppHarbor. You should see something like this:

RestorePackages:
  "D:\temp\x2iood3j.ltv\input\.nuget\nuget.exe" 
      install "D:\temp\x2iood3j.ltv\input\NuGetPackageRestore\packages.config" 
      -source "" -o "D:\temp\x2iood3j.ltv\input\packages"
  Successfully installed 'elmah 1.2.0.1'.
  Successfully installed 'elmah.corelibrary 1.2.1'.

Look Ma!, no packages directory:

This post will demonstrate how to do rock-solid phone number validation using the .NET port of Google's libphonenumber. When validating phone numbers you tend to end up either frustrating users with strict input requirements or with complicated regexes to cover all the interesting ways that users input phone numbers. If you have to also check international numbers (as we do at AppHarbor) the task becomes almost impossible.

Enter libphonenumber, a library from Google containing years of accumulated wisdom on how to parse phone numbers from all over the world. Patrick Mézard has created a .NET port of the Java version and there is even a NuGet package.

This makes using libphonenumber for validation as easy as installing the NuGet package and wrapping it in a DataAnnotation attribute like the one below (or just use the library straight up). The Attribute below will parse US numbers with and without country code while international numbers require a country code. Example of use:

using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
using MyNamespace.DataAnnotations;

public class Address
{
    [DisplayName("Phone number")]
    [PhoneNumber]
    [Required]
    public virtual string PhoneNumber
    {
        get;
        set;
    }
}

Attribute:

using System.ComponentModel.DataAnnotations;
using PhoneNumbers;

namespace MyNamespace.DataAnnotations
{
    public class PhoneNumberAttribute : ValidationAttribute
    {
        public override bool IsValid(object value)
        {
            var valueString = value as string;
            if (string.IsNullOrEmpty(valueString))
            {
                return true;
            }

            var util = PhoneNumberUtil.GetInstance();
            try
            {
                var number = util.Parse(valueString, "US");
                return util.IsValidNumber(number);
            }
            catch (NumberParseException)
            {
                return false;
            }
        }
    }
}

Unit tests for attribute:

using MyNamespace.DataAnnotations;
using Xunit;
using Xunit.Extensions;

namespace MyNamespace.UnitTest.DataAnnotations
{
    public class PhoneNumberAttributeTest
    {
        private readonly PhoneNumberAttribute _subjectUnderTest;

        public PhoneNumberAttributeTest()
        {
            _subjectUnderTest = new PhoneNumberAttribute();
        }

        [Fact]
        public void GivenNull_WhenValidate_ThenIsValid()
        {
            Assert.True(_subjectUnderTest.IsValid(null));
        }

        [Fact]
        public void GivenEmptyString_WhenValidate_ThenIsValid()
        {
            Assert.True(_subjectUnderTest.IsValid(string.Empty));
        }

        [InlineData("+4527122799")]
        [InlineData("6503181051")]
        [InlineData("+16503181051")]
        [InlineData("1-650-318-1051")]
        [InlineData("+1-650-318-1051")]
        [InlineData("+1650-318-1051")]
        [Theory]
        public void GivenValidPhoneNumber_WhenValidate_ThenIsValid(string phoneNumberString)
        {
            Assert.True(_subjectUnderTest.IsValid(phoneNumberString));
        }

        [InlineData("123")]
        [InlineData("foo")]
        [Theory]
        public void GivenInValidPhoneNumber_WhenValidate_ThenIsNotValid(string phoneNumberString)
        {
            Assert.False(_subjectUnderTest.IsValid(phoneNumberString));
        }
    }
}

AppHarbor has been available in public beta for one year and we wanted to share some incredible statistics. Our users clocked more than 26,871,840 hours of free hosting. AppHarbor received an amazing 117,587 builds. 18,291 builds did not compile or failed unit tests and AppHarbor stopped them from going live. We deployed and scaled 99,296 builds!

AppHarbor cares deeply about our community. We responded 4,201 times on our support forum, our median response time is 1h 34m. Our community is not only on AppHarbor and we go where they go, including a thriving community on Twitter and a fast growing group on one of our favorite sites, StackOverflow.

When we founded AppHarbor, we set out to give .NET developers everywhere an amazing platform to deploy and scale their applications in the cloud. A portable platform so that developers could move their application somewhere else without any hassle. A platform where developers could easily use 3rd party add-ons to enrich their applications. A platform where any developer can throw together an application and deploy it live for free. And a platform that our users could rely on.

We are committed to always have a free offering. Through the last 12 months one of the biggest concerns we have heard from customers, is that you haven't been able to pay us. We realise you want to know that we will be around for years to come. We always planned on offering premium plans, and today we are announcing two new premium plans.

Meet Catamaran and Yacht which will complement our newly branded Canoe free plan. Canoe comes with one worker, a complimentary yourapp.apphb.com subdomain and piggyback SSL using the apphb.com certificate.

Like all AppHarbor applications, apps on the Canoe plan have access to our build service and continuous integration infrastructure. This includes built-in source code repositories, integrations with external source code repository providers such as BitBucket and GitHub, source code compilation, unit test execution and notifications for completed builds. Canoe apps also have access to the full catalog of add-ons many of which have free plans. Canoe apps are load balanced from the start, so it's ready to scale out when you need it.

Catamaran, at $49/month, gives your application 2 workers along with custom hostnames and SNI SSL. Yacht comes with 4 workers, custom hostnames and IP SSL for $199/month. Multiple workers are recommended for production applications, they increase the number of requests your application can handle and ensure that your application runs with no downtime in case of a sudden server failure. That is why we built it in to our paid plans.

If you are happy with the Canoe plan and just need custom hostnames or SNI SSL, those can be added a la carte for $10/month. If your app needs IP SSL with either the Canoe or Catamaran plans, that can be had for $100/month. Additional workers are $49/month and can be added to any plan.

The workers in our plans can be used as either web or background workers. Background workers are not available yet, but we are working hard on the remaining pieces and will launch a beta shortly.

Applications that already have custom domains or are using SNI SSL can keep using those for free for another month, until March 1st. Once the grace period expires, we will either start charging (if a credit card is added to your account) or downgrade the app. Applications that are currently scaled to two or more instances will be placed on the Catamaran plan.

We want our prices to be as straightforward as the platform itself. You don't need to calculate how much I/O you're going to use, or what amount of bandwidth you require. We've set some soft and hard limits, but chances are that you'll never exceed those.

We chose to charge for custom domains because our free plan is meant to be a great developer sandbox. Custom domains are a sign that what is being built requires a certain branding, whether it is a business product or even a personal blog. We think it is fair that users who get value from using AppHarbor share the costs of running the platform. We kept the price of a custom domain low and we do not intend to make money from it. In fact we plan to donate any profits generated by custom domains to open-source projects and charity! In addition, we are looking at other ways to support applications that provide a valuable service to the .NET community, non-profits and education, for example by extending additional free resources to such apps. Please drop us a line if you think your application qualifies.

Charging for AppHarbor ensures you can keep using our service in the future. It also means that we can start to offer more advanced features - starting today scaling to more than two workers and IP SSL is generally available to all customers. As always, we value your comments and feedback and look forward to keep improving what we already think is the best .NET application platform.

At AppHarbor, there is nothing we like more than getting out and talking to developers that use our platform. Meeting our users is our best chance of understanding how you are using AppHarbor and what challenges you are face crafting great .NET applications.

Last year we talked at Øredev, GOTO Aarhus, Alt.NET Seattle and Community Day in Copenhagen. We also did a meetup at AppHarbor HQ in San Francisco, organised a Code Retreat in Copenhagen and generally tried as much as possible to be around when interesting .NET stuff was happening.

This year we are already booked to appear at DevSum in Stockholm, GOTO Copenhagen and at the Norwegian Developer Conference in Oslo and we're working on getting to a bunch more. If you're going to a conference that you'd like to see someone from AppHarbor give a talk at or if you're organizing a conference and you want someone from AppHarbor to come then please let us know. We love to talk about building great .NET applications, continious delivery, how to take advantage of cloud platforms, how we built AppHarbor and what we've learned from helping developers move their apps onto AppHarbor. We promise to always bring plenty of delicious AppHarbor schwag.

Don't forget that Lanyrd is a great resource when deciding what conferences to attend. Check out the .NET topic and the "Microsoft Guide" (curated by @shanselman).

Today we're happy to announce beta support for node.js, and you can now run your node.js applications on AppHarbor. In this blogpost we'll walk you through the things you should be aware of when deploying node.js apps to AppHarbor and some background on why we're adding support for it.

As you probably know by now we're committed to giving the .NET world the fastest and most convenient way to deploy, manage and scale applications on Windows-based servers in the cloud. As such we didn't immediately think of node.js as the most obvious second platform to support. With recent developments in the node.js community, in particular Microsoft's support of a native Windows implementation along with the performance and stability it brings, node.js on Windows has become viable.

A number of fiery talks by Glenn Block on why node.js has a place in the Windows world further pushed us to make this decision. Finally Tomasz Janczuk made it incredibly easy for us to support it with the iisnode project, which allows us to run node.js inside IIS.

Without further ado let's dive into preparing and deploying a node.js application on AppHarbor. As this is a node.js blogpost we'll of course deploy a chat application and will use Ryan Dahl's node chat demo application. Applications that use iisnode needs a web.config in order to configure the application in IIS. When developing the application you can easily test it by installing iisnode and it's dependencies on your local system which are listed on the Github page. Make sure to take a look at the samples included to get a better understanding of how you can use the web.config file to configure your application.

Start by cloning the application from GitHub:

git clone https://github.com/ry/node_chat.git

The node chat uses the server.js file as the starting point, so we'll make sure to register that in our new web.config

<configuration>
    <system.webServer>
        <handlers>
            <add name="iisnode" path="server.js" verb="*" modules="iisnode" />
        </handlers>
        <iisnode loggingEnabled="false" />

        <rewrite>
            <rules>
                <rule name="myapp">
                    <match url="/*" />
                    <action type="Rewrite" url="server.js" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Most of this is taken from the express sample web.config which show the iisnode module is configured to handle the server.js file and alse how URL rewrites are configured so we don't have to use the filenames directly. Two things are worth noting:

• Disable logging: The iisnode elements sets loggingEnabled="true" which is necessary to run your node.js application on AppHarbor. The iisnode module writes a log file to the directory where the application runs and writing to the filesystem is not supported by default on AppHarbor. Alternatively, you can enable instance file system writes in the application settings on AppHarbor.
• Environment variables: iisnode automatically configures the node.js application with environment variables read from appSettings. In the example above the `NODE_ENV` variable is set. This sets the current node environment and you could should add a configuration variable on AppHarbor with the value "production". That value will then be replaced when you deploy the application as [described here](http://support.appharbor.com/kb/getting-started/managing-environments). If you've provisioned [add-ons](https://appharbor.com/addons) to your application their configuration variables will also be automatically injected.

With this configuration we're good to go and the application can be deployed to AppHarbor:

git remote add appharbor https://appharbor.com/<foo>.git
git push appharbor master

That's it - AppHarbor will the detect the node.js application and deploy it to the the application server. Go to the application's URL (this example is deployed here if you want to take a look) and start chatting with all your friends.

A couple of final remarks:

• NPM: If you're using NPM you'll have to make sure that all dependencies are included in the repository. We may support automatic download of dependencies with NPM in the future, but are waiting until a stable Windows version is ready.
• Websockets are not currently supported
• Node.js support on AppHarbor should only be used for development and beta testing purposes. We wanted to give our users the opportunity to try node.js soon and iron out any kinks with us, but for now this feature should be considered early beta. Please don't put your "mission critical" node.js apps on AppHarbor just yet.

Unless you've been living under a rock for the past month, you've probably heard of the SOPA and PIPA laws that are making their way through the US Congress. If passed, the laws will require US companies to censor the Internet in an effort to prevent copyright infringement.

We built AppHarbor because we love the Internet. AppHarbor makes it easy for people like you to make the Internet even better by taking the pain out of deploying and scaling web-applications. We feel strongly that the SOPA and PIPA laws, if passed in their current form, pose a grave threat to the free and open Internet that we know and love. For that reason, we support the January 18th protests alongside Google, Wikipedia and many others.

If you want to participate in the protest by blacking out your AppHarbor-hosted application, we have created a Stop-SOPA utility that makes the process very simple. Go to https://stopsopa.apphb.com/ to get the details. The utility will cause a blackout-page build to be deployed for your application in the same way that MaintMan deploys a maintenance mode page. Once you're done protesting, you can push a new build to AppHarbor or go to the application dashboard to deploy a previous build.

The Stop-SOPA utitlity uses some clever new bits of AppHarbor API. We will publish the source code in another blog post in a day or two.

Note that appbarbor.com will be available in its usual form throughout Wednesday 18th, but we support and encourage blackout protests by our users.

The first featured app of 2012 is WorkFu. WorkFu is headquartered in London, but the founding team is spread all over the UK. We talked to Neil Kinnish about the project.

What is WorkFu?

WorkFu is a web application that uses your social networks to find work opportunities that are relevant to you.

You can read more about the project and how it works and follow our progress on Twitter

Why did you choose AppHarbor?

We chose AppHarbor because we needed a reliable, scalable cloud based hosting service. AppHarbor gives us freedom to pick and choose the correct tools for our requirements and budget without locking us down to technologies and without high upfront costs. We also like the fact that we can provision Amazon services in the same location that our application is running.

Which technologies is WorkFu built on?

WorkFu is built on MVC 3 and utilises: Redis, Memcached, Autofac, Lucene, Dapper.net, SignalR, jQuery, Booksleeve, Elmah, MS SQL Server 2008, S3 for file storage and Postmark for mail delivery

We have background services running on separate Amazon instances along with our Redis and Memcached implementations.

How has AppHarbor worked for you so far?

AppHarbor is Superb. There are obvious benefits, such as being able to scale on demand. And it’s a joy managing the work flow through Git, especially as we all work remotely.

I should also mention that the support so far has been excellent.

How often do you deploy new versions?

Continuously. The project is in a constant state of development and progress.

What did you like best? Where could we improve?

One of the most important elements to any service is the support and this should not be under estimated. I’m happy that along with a great service you have got this element right.

Anything else?

Yeah, keep on pushing forward and doing great things.

AppHarbor uses ASP.NET Health Monitoring to log and display exceptions thrown by applications running on the platform. Enterprising AppHarbor users have used this feature for debugging purposes by throwing exceptions from their their code. Throwing an exception is inconvenient however, since doing so interrupts normal program flow.

Below is a simple example demonstrating how to subvert ASP.NET Health Monitoring and make AppHarbor log messages. Logged messages are available for inspection in the application Error Display and logging messages like this does not involve throwing an exception.

Note that this is not anything like a replacement for application event tracking solutions such as Airbrake or Logentries, but it's pretty neat if you just need a simple way to output some debugging information while your application is running on AppHarbor.

using System;
using System.Web.Management;
using System.Web.Mvc;

namespace ErrorLoggingSample.Controllers
{
    public class ErrorController : Controller
    {
        public ActionResult Index()
        {
            new LogEvent("message to myself").Raise();
            return View();
        }
    }

    public class LogEvent : WebRequestErrorEvent
    {
        public LogEvent(string message)
            : base(null, null, 100001, new Exception(message))
        {
        }
    }
}

As of today, you can provision StillAlive as an add-on to AppHarbor applications. StillAlive is a great way make sure your application is functioning correctly beyond just checking that accessing front page gives a HTTP 200 response. With StillAlive you can write test recipes checking that your login flow works, for example. This is a great feature for frequently updated AppHarbor applications

The StillAlive guys have written guides on Installing StillAlive and Creating your first Test Recipe.

Today, we have added Cloudmailin and JustOneDB to the AppHarbor add-on catalog.

Cloudmailin is an incredibly simple way to let you AppHarbor-hosted application receive emails without having to mess with SMTP servers. Simply provision the Cloudmailin add-on, configure Cloudmailin to POST to an url in your app that can receive Cloudmailin posts and hand out the Cloudmailin-provided email address to people that should send emails to your app. There's additional documentation on how to get started with CloudMailin on the AppHarbor support site.

JustOneDB is a fast, no admin, no tuning general purpose database designed and built for the cloud. You can interact with JustOneDB using either a REST API or though a PostgreSQL-compatible interface. We have written a complete sample MVC app using NHibernate interacting with JustOneDB through the PostgreSQL interface. Additional JustOneDB documentation is available on the AppHarbor support site.

We hope you'll take advantage of Cloudmailin and JustOneDB and all the other add-ons in our catalog to quickly build great .NET apps running on AppHarbor. We're working hard on adding many more add-ons to the catalog.

When you visit appharbor.com you will now be browsing the new and redesigned AppHarbor website. We're really happy with the way the new site looks and feels and we hope you will have the same experience using it. A sea dragon called Frode was adopted as part of the redesign and we hope you'll give him a warm welcome too.

If you look under the covers of the new design, you will notice plenty of HTML5 goodness and there is plenty more coming as we build out the interactive features of the new design.

We're getting stickers, t-shirts, sea-dragon-shaped thumb-drives and all the other schwag-paraphernalia of a startup so that you can soon show-off that you use AppHarbor to build and host .NET applications.

We know there are some nooks and crannies that need a little more work (and we need to port the new design to the blog) and we'll be attending to that over the next few weeks. If you find anything that's broken or not looking right in your browser of choice then don't hesitate to report it to support@appharbor.com.

We're excited to announce that AirBrake is now in the AppHarbor add-on catalog. AirBrake is a great way to track errors and exceptions in your AppHarbor hosted application. We have written a short guide to get you started logging errors to AirBrake from your AppHarbor application.

We have just flicked the switch and you can now provision paid add-ons for your AppHarbor applications. You can also upgrade already provisioned add-ons from free plan to paid plans.

When we launched add-ons, only free plans were available. This was because we wanted to iron out any kinks in the add-ons and in the provisioning flow, before taking your money. We are excited that AppHarbor users now have full access to the powerful add-ons in the AppHarbor add-on catalog.

Prices quoted in the catalog are per-month and per-application that you provision the add-on to. Prices are pro-rated for months where the add-on was not provisioned the entire month. To provision or upgrade to a paid add-on, you have to provide a valid credit card in the same way as when trialling scaling

We are aware that add-ons can nominally be shared by multiple applications if you are willing to copy around configuration variables. This practice is not recommended and not supported. This is because add-on providers may at any time update the configuration variables for a provisioned add-on. This may for happen, for example, if an add-on provider's server crashes and your application needs to be made aware of what new server to use. Applications with configuration variables copy-pasted from another application will not get the new configuration values until you actively copy-paste and push the updates.

The Sequelizer add-on has had a 10GB trial plan since AppHarbor's inception. That will now become a paid plan offered for $10/month. If you have provisioned 10GB Sequelizer add-ons and your account has a valid credit card, we will start charging effective December 1. Accounts with no credit card will have a grace period lasting until December 1, after which we will downgrade databases to the free plan (20MB). If the database contains too much data to be downgraded, it will be placed in read-only mode. If you have Sequelizer databases provisioned to any of your AppHarbor applications, please verify that they are provisioned with the plans you want.

Paid add-ons marks the second step of AppHarbor beginning to take money for the services we provide (the first step was taking credit card details to enable scaling). Your input in this process is greatly valued and we encourage comments on this post or emails to support@appharbor.com if you have thoughts on add-on pricing or want to let us know what you would pay for AppHarbor deployment and scaling.

Note that some add-on providers in the AppHarbor catalog do not currently support changing plans. For those add-ons, you will have to remove the add-on from your application and then reprovision it with the plan you want.

Last week, IndexTank announced that they have been bought by LinkedIn. At AppHarbor, we're incredibly happy for the IndexTank team and wish them the best in their future ventures as part of LinkedIn.

For AppHarbor users, the acquisition means that provisioning IndexTank to AppHarbor applications is no longer possible, and that the IndexTank has been removed from the add-on catalog. IndexTank add-ons provisioned on AppHarbor before the announcement still work, and will continue to due so for another six months. We will contact AppHarbor users using the IndexTank add-on with additional details.