We recently announced our pricing and mentioned that we intend to continue supporting and promoting the .NET ecosystem. As part of that effort we're launching the AppHarbor Community Application program ("CAP") today. AppHarbor will support applications under the program with various services such as free cloud hosting and promotion targeted at .NET and Windows developers.

Any individual, organization or company that provide nonprofit services benefitting the .NET and Windows developer ecosystem are encouraged to apply for inclusion in the program. Examples of qualifying entities are developer user groups, open source projects, community services and online developer tools.

What's the deal

All applications under the program will be subscribed to our recommended plan, Catamaran, at no charge. The Catamaran plan includes 2 workers for redundancy and increased HTTP performance. Additionally custom hostnames can be associated with the application and SNI SSL support comes out of the box. This is of course in addition to the services that are included in all plans, such as our continuous integration setup. In return we ask that you mention AppHarbor on the application webpage and that we can refer to the application from time to time. If you need more resources than we provide by default let us know and we'll evaluate that along with your application.

We'll continue to expand the program and how we help the community with it. If you have suggestions on how we can support your project even better we'd love to hear them!

Apply

Apply today on support.appharbor.com or shoot us an email on [email protected] to be included in the program. Please include a brief description of the type of application you want to run, a link if applicable and why you think it should be supported under the AppHarbor CAP.Please refer to the CAP terms for more details.

Note: Users that have already applied for inclusion in the program will receive a response over the next few days

UPDATE: We have published a replacement for ASP.NET forms authentication.

Forms Authentication is the default way for ASP.NET applications (both MVC and Web Forms) to keep track of logged in users. Unfortunately forms auth is subtly broken in a way that can cause problems for applications running on multiple machines in load-balanced setups and web farms such as the one found on AppHarbor's cloud platform.

Forms authentication in an ASP.NET application works by setting encrypted cookies in users browsers on log in (forms authentication also has a uri-mode for clients that don't support cookies). When a user returns to the site, ASP.NET will identify the user by decrypting the cookie passed by the users browser.

How the cookie is encrypted and made tamper-proof is configured in the machineKey element in the application web.config. The standard ASP.NET behaviour is to AutoGenerate the keys. This setting causes new keys to be generated every time the application pool is started. If a user shows up on the site with a cookie created with old keys, the cookie is not recognized and the user will have to log in again. This is not desirable, especially since IIS may decide to stop an inactive application to conserve resources and then restart it when a visitor shows up.

Auto-generating machine keys also won't work if an application is running on multiple servers. This is because cookies issued by one server, using the keys that server has auto-generated for the application, will not be recognized by another server that has generated a different set of keys.

AppHarbor overcomes these limitations in the following way: When the AppHarbor platform deploys an application, the web.config machineKey element is examined. If the machineKeys are set to auto-generate, that setting is overriden and machineKeys unique to that application are specified. If the machineKeys are already set to a fixed value, they are left alone. This means that sessions in applications hosted on AppHarbor survive application pool restarts. Also, because all web workers of an application that is scaled to multiple workers use the same machineKeys, cookies issued by one worker are accepted by all other workers running that application.

Here's an example machineKey element inserted by AppHarbor.

<machineKey validation="SHA1"
    decryptionKey="someDecryptionKey"
    validationKey="someValidationKey" />

So where's the breakage? As long as all application workers are using the same set of machineKeys, everything should be peachy, right? Well, not quite. It turns out that Microsoft has a tendency to change the way forms authentication cookies are generated as patches to ASP.NET are issued. Changing the way cookies are encrypted might make sense for major version updates or if security problems are found, but changes seem to happen more often than that. It's especially strange since the encryption algorithm to be used (SHA1, AES, etc.) is specified in the machineKey element, suggesting that something else is changing with the patches (i.e. a salt).

While we can't always nail down what patches cause cookie-incompatibilities it definitely happened (and was announced) for the late December 2011 security update. We have also detected problems both before and after that event, however.

Semi-frequent updates of the cookie-algorithm makes sysadmins lives (including ours) more difficult. Instead of doing rolling patch updates across platform servers — i.e. move all application worker off a server, patch and reboot it, move application workers back — we have to crank up an entirely new set of fully patched servers and move all workers running an application in one go. Solving these kinds of problems for developers is why we started AppHarbor, of course, but some problems we can't solve. There's no way to prevent users logged in using forms auth from having to log back in after an update like this, for example.

The best way to get around this problem is to not use forms authentication at all: If you control how authentication cookies are generated, then no Microsoft patch is going to come along and mess things up. Indeed, this is how AppHarbor.com works and we hope to soon provide a sample of how you can do the same in your application.

To debug forms authentication problems we have used this simple application which lets you log in using forms authentication and determine cookie status on the various servers that run the application.

As always, we're committed to making AppHarbor the best platform for deploying and scaling your .NET applications. This post described some of the steps we take to do just that and provided guidance on ways you can adapt you application to ensure maximum reliability and continuity for your users. If you have questions on how to best scale your application on AppHarbor, then feel free to get in touch.

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.