UPDATE: .NET 4.5 is now available on AppHarbor.

Like all of you, we've been eagerly awaiting the release of .NET 4.5. We have also promised to add .NET 4.5 support to AppHarbor as soon as it went RTM. That happened August 15th and it's now the 20th, so what's with the delay?

The delay is due to a bug that we uncovered while testing to make sure that adding .NET 4.5 to AppHarbor build servers would not cause problems for existing applications targeting other .NET framework versions. It turns out that using MSBuild to build projects that target .NET 3.5 on a system that has .NET 4.5 RTM installed, fails – but only if the user account running the build process has a username that is 20 characters in length and only if the project contains resource files (.resx) . 20 characters is generally the maximum length of usernames for Windows users and it's the length of usernames that AppHarbor uses for user accounts created to perform various tasks on the platform.

Here's how to re-create the bug on a system with both .NET 3.5 and 4.5 installed:

• Create a user with a username that's 20 characters long
• Log in as that user and open Visual Studio
• Create any C# project (a console app is known to trigger the bug)
• Change the target framework to 3.5
• Add a resource file (.resx) to the project
• Build the project

We've made Microsoft aware of the problem and we're working on a workaround. We expect final .NET 4.5 testing to complete in a few days at most and from then on you'll be able to build, test and run .NET 4.5 apps on AppHarbor.

To keep you occupied until then, we're accepting explanations for the cause of the bug in the comments: Why do you think MSBuild fails to build projects with resource files on systems with both .NET 3.5 and 4.5 if the current user's username has a length of 20 characters? The funniest/most-creative/most-accurate guess wins an AppHarbor t-shirt.

We've got a new add-on for you: CloudBird, an awesome hosted RavenDB service. CloudBird is currently available in the EU and will give low latency for apps hosted in AppHarbor's EU- region. The CloudBird guys have assured us that support for additional regions is on the way.

Once you provision CloudBird, you can use the RavenDB connectionstring from your app. Check out the full docs for all the details.

If you've been waiting for a low-latency RavenDB service for your EU-based AppHarbor app, then CloudBird is the add-on for you.

On August 3rd, we published a blog post on how to replace ASP.NET forms authentication with accompanying example source code. Both the code and the post were pulled down a few hours later, but we're happy to report that both are now back up. This post describes why we removed the blog post, why it's now back up and provides additional details on why we think having an alternative to ASP.NET authentication solution is a good idea.

We pulled down the post on Friday because we got a note from people at Microsoft who were worried that the solution we had published was unsafe. We were pretty confident in the implementation but given the gravity of the matter we felt that this was the best thing to do. In the end, Microsoft named no vulnerabilities and were primarily concerned that our motivation for replacing ASP.NET forms authentication (as outlined in a February blog post) was wrong*. To recap, our argument is that the forms authentication cookie payload format changes semi-frequently with .NET updates and that causes problems for application maintainers. By using your own authentication implementation (like the one we published), you control the cookie format and when it changes.

Invalid cookies is not only one reason why we think an alternative is relevant. ASP.NET is somewhat unique among major web application frameworks in that only one authentication solution is available. Having multiple alternative authentication solutions means that a weakness discovered in one of them won't let an attacker bring down all ASP.NET sites on the web. This decreases the incentive to try and break any one implementation and that makes everyone safer.

The way Forms Authentication is baked into the .NET Framework also poses some challenges:

1. Changing the mechanism is difficult because it requires publishing security advisories, conducting outreach and rolling out Windows and .NET Framework updates
2. Encryption keys (from the MachineKey configuration element) can potentially be used for multiple purposes. This increases the risk that a key is obtained by an attacker by analyzing other encrypted payloads
3. Forms Authentication is not very extensible and implementing something like revocable sessions is difficult

Lastly – and this is a nitpick compared to the points above – we think standard Forms Authentication tends to saddle unwary developers with poor application design. The most expedient way to get started with Forms Authentication is to use the aspnet_regsql to auto-generate tables required to store users, roles and membership info. Developers then end up with users records stored either in a database separate from the database that stores application records or in disjointed table systems that are hard to combine. Not exactly the Pit of Success. Our implementation may take a little more effort to add to an existing project, but we think it's much easier to integrate well.

We're excited to make this sample available again. We welcome and look forward to your scrutiny, comments and any pull requests the ASP.NET community might have. With this release, we want improve choice for ASP.NET developers and – with your involvement – help you create better and more secure applications running on the ASP.NET platform.

--

* To be fair, Microsoft did eventually allude to one potential weakness, namely that cookies were not HMAC signed. We had already identified this problem and the example code has been updated.

Today we're featuring Source Code Reader, a web application that let's your effortlessly browse C# code on GitHub without having to clone the repository and fire up Visual Studio. We talked to Rajeesh, the creator of Source Code Reader.

Tell us a little bit about Source Code Reader

Source Code Reader is a web application which basically allows a user to open a publically hosted .NET C# project on Github and navigate through the code seamlessly. It allows a user to navigate directly to the implementation code from the calling code with single click (similar to the Go To Definition feature available in Microsoft Visual Studio).

Source code hosting providers like GitHub, Bitbucket, CodePlex and Google Code only provide provide basic file browsing capabilities. Source Code Reader does much more than files browsing; it understands the semantics of the code to give superior code navigation functionality.

What inspired you to build Source Code Reader?

One day I was going through the RavenDB source code hosted on Github and it was really difficult to find out how a method or class is implemented when looking at the calling code. The only way was to manually go through all the folders to find the implementation. It's not a big problem for simple projects but for project like RavenDB it is a daunting task. Source Code Reader solves this problem.

What technologies are you using

Source Code Reader is an ASP.NET MVC 4 single page application. Other technologies include:

• Microsoft Roslyn is used for all the syntax and sematic analysis
• Lucene.Net for indexing data
• Web API for serving content from server
• Knockoutjs for the client side UI rendering and SignalR for push notifications
• Logentries add-on for logging

What's in store for the future?

Lots of things are on my list, here are some:

• Better syntax highlighting
• Support for VB.NET
• Supporting other source code hosting providers like Bitbucket, Google Code and CodeOlex
• Support for other languages (longer term)

If you want to help make this happen, then feel free to pitch in – Source Code Reader is open source and I'd love to get contributions.

UPDATE: This blog post was briefly unavailable, we've published an update on why it was taken down.

Several months ago, we wrote a blog post about why we think ASP.NET forms authentication is broken. The post describes how the cookie encryption in ASP.NET tends to change with Windows updates and patches, the problems it causes for a platform like AppHarbor, and the steps we take to mitigate those problems.

In the comments, we promised to share our solution to fix the breakage in ASP.NET forms authentication and that solution is to replace it with our own authentication implementation entirely. This gives you complete control over how the session cookies are created, so that there's no way they'll be affected by changes to the .NET Framework or other pieces of the infrastructure.

We have chosen to share this by open sourcing an authentication class library and a bare-bones ASP.NET MVC application with a fairly complete authentication implementation. It's available on GitHub; go take a look now.

What's included

• There are three projects, the sample, the AppHarbor.Web.Security class library and a KeyGenerator
• Password hashing is done using Blowfish-based BCrypt. BCrypt is nice because it's an adaptive hash function that can be made slower to compensate for attackers getting access to progressively faster hardware used to brute-force any salted and hashed passwords they've gotten access to.
• Just like ASP.NET forms authentication, encrypted cookies are used to track sessions. Cookies are encrypted using the fast symmetric Rijndael algorithm
• The Web project comes with a UserController to create new users, and a SessionController to sign existing users in and out

Check out the README has details on how to integrate the authentication implementation in your own project. You can also refer to the sample for inspiration.

Once this solution has been available for public scrutiny for a while and we're confident that it is sound, we will package the authentication library up as a NuGet package to ease installation.

Let us know how this works out for you in the comments, and feel free to get in touch if you encounter any problems.

Image credit: Brocken Inaglory

AppHarbor supports applying Web.config transformations when applications are deployed on the platform. We also built a popular tool that you can use to test your config transformations live.

In addition to applying any transforms you push with your code, we use the Web.config transformation API to perform various other types of configuration transformations that have to happen for the platform to work. For example, for add-ons that require setup more sophisticated setup than simply injecting settings into the appSettings element.

The built-in vocabulary of transforms is somewhat limited, especially if you have to write transforms that must work correctly with all the varied Web.config files encountered by AppHarbor and not just with your own well-known config file. Fortunately, the Web.config transform engine can be extended to support additional transformations.

The API that external transforms have to implement is found in the Microsoft.Web.Publishing.Tasks namespace. It's unpleasant and not documented by Microsoft but information can be found in this blog post and in this Stack Overflow answer.

A Transform that we needed was one that would insert an element if it's missing but leave the element alone if it's already present. Imagine, for example, that AppHarbor needs to be able to add connection strings to the connectionStrings element. If we encounter a Web.config file without a connectionStrings element, we need to first insert a new element and then add the connection string in question to that. If the connectionStrings element is already present, we want to leave any connection strings it contains alone and just add the new one.

To accomplish this, we extended the transform engine with a Merge transform that looks like this:

using System.Linq;
using System.Xml;
using Microsoft.Web.Publishing.Tasks;

namespace AppHarbor.TransformTester.Transforms
{
    public class Merge : Transform
    {
        public Merge() : base(TransformFlags.UseParentAsTargetNode)
        {}

        protected override void Apply()
        {
            Apply((XmlElement)TargetNode, (XmlElement)TransformNode);
        }

        public void Apply(XmlElement targetElement, XmlElement transformElement)
        {
            var targetChildElement = targetElement.ChildNodes.OfType<XmlElement>()
                .FirstOrDefault(x => x.LocalName == transformElement.LocalName);
            if (targetChildElement == null)
            {
                targetElement.AppendChild(transformElement);
                return;
            }

            foreach (var transformChildElement in transformElement.ChildNodes
                .OfType<XmlElement>())
            {
                Apply(targetChildElement, transformChildElement);
            }
        }
    }
}

To use a custom transform, you have to import the relevant namespace in your transformation XML:

<xdt:Import assembly="AppHarbor.TransformTester"
    namespace="AppHarbor.TransformTester.Transforms"/>

You can then use it to add the connectionStrings element, if it's missing, like this:

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
    <connectionStrings xdt:Transform="Merge" />
    <connectionStrings>
        <add name="bar" connectionString="value" xdt:Transform="Insert"/>
    </connectionStrings>
</configuration>

We have added our custom transforms to the Web.config transformation tester which is open source (and we accept contributions). Check out the Merge and MergeBefore (which takes an XPath expression like InsertBefore) transforms and the unit tests to get an idea of how custom transforms work. And give them a try live on the transformation tester running on AppHarbor.

We're excited to announce that, as of right now, you can push code to AppHarbor using Subversion! This thanks to SVNSailer, an add-on that we just enabled.*

Once you add SVNSailor to your application, you need to authorize the add-on with your account to let it schedule builds for your app. With that done, you tell SVNSailor what Subversion repository to fetch code from, and from then on, you can schedule builds to AppHarbor from the interface. Here are the steps required:

1. Add SVNSailor add-on
2. Go to SVNSailor from the application dashboard
3. Click "Settings"
4. Authorize
5. Add Subversion repository info
6. Start queuing builds on AppHarbor

SVNSailor has support for automatic build triggers. The urls (there's a standard one, and one for Beanstalk) are currently injected into the application as configuration variables but we've asked the SVNSailor guys to also display them in the interface.

SVNSailor makes good use of both the AppHarbor build API, OAuth authorization of AppHarbor users for external services and of course the add-on API.

--

* Using Subversion with AppHarbor has been technically possible using CodePlex and GitHub for a while.

A few weeks ago we profiled the Appfail exception monitoring application on the blog. Appfail lets you track, monitor and analyse exceptions in ASP.NET applications.

AppFail is now available as an AppHarbor add-on. This makes adding Appfail to your AppHarbor-hosted application even easier: Simply install the relevant NuGet package, provision the add-on and then all necessary configuration will be injected when you deploy.

AppFail itself runs on AppHarbor and you can read more about how it works and how it was built in the previous blog post.

Don't miss the chance to fix bugs in your code because you're not accurately tracking exceptions. Provision the Appfail add-on now.

The AppHarbor API Contest got lots of great entries that we will be profiling over the coming weeks. Today we're talking to Steve Hanna, the man behind Harborfront. Harborfront is an Android app that you can use to monitor and manage your AppHarbor applications on the go.

Why did you build Harborfront?

I built Harborfront to manage and monitor my AppHarbor apps from my android phone. Harborfront implements most of the API but was originally built to solve the following problems:

• Primarily, I wanted to be able to quickly roll back a previous build in case of an emergency–like when I foolishly deployed a buggy version in a rush only to find out from an angry customer.
• The other interesting use case was to be able to receive push notifications on my phone after a completed build. This is particularly useful when working in teams where deployments happen frequently.

What technologies are you using?

Harborfront is a native mobile application built on the Android SDK using Java. The app uses ActionBarSherlock in order to backport the action bar design pattern to older versions of Android.

In order to get push notifications working, Harborfront uses Google Cloud Messaging which requires a server-side component to send messages and register devices. For this I’m using ASP.NET MVC 3 with RavenDB as the data store. All built on top of AppHarbor, of course.

What advice would you give to other developers using the AppHarbor API?

If you’re working in a .NET environment then definitely leverage AppHarbor.NET. If you’re not (e.g. if you're building for Android) then there’s nothing to be afraid of: AppHarbor’s RESTful API is a pleasure to work with. The OAuth implementation can be tricky but the API documentation is well written so be sure to lean on it when you get stuck.

What's in store for the future?

There are still a few unimplemented API features which are all pretty low hanging fruit. On the server side, I’d like to be able to push more notifications to devices, like error messages. However, because this isn’t available in the API this will require polling AppHarbor.

Any final thoughts?

This was a fun little project and the source code is available on GitHub if you’d like to have a peek under the hood or contribute. You can find me on Twitter (@SteveHanna) for Harborfront’s progress or to report issues and feedback.

We got a lot of great entries for the AppHarbor API Contest and we've been busy testing and trying out the submissions. We were excited to see all the stuff you guys built on top of the API and we can't wait to see more. All contestants who submitted an entry get an AppHarbor T-shirt and we'll be mailing those out shortly.

The winners of the main prices are:

1. AppHarbify – instantly deploy open source software to AppHarbor, built by Chris Sainty
2. Lookout – an AppHarbor build watcher by Matt Warren
3. MobileAppHarbor – a mobile optimized HTML client by Wyatt Preul

AppHarbify has been around for a while but we still think it's the best use of the AppHarbor API. AppHarbify uses the API to elegantly provision and deploy open source .NET code to AppHarbor including provisioning add-ons and adding configuration variables required for the project to run. Even better, AppHarbify is template-based and adding support for additional .NET open source projects is simple. The templates are JSON-based and adding support for your favorite project is as easy as forking, adding the project, testing that everything works and issuing a pull request.

Lookout is a desktop build notifier that sits in your system tray and monitors your AppHarbor application builds. We love Lookout because it profiles the cloud continuous integration aspects of AppHarbor and we think that deserves more attention. Remember, AppHarbor builds your code and runs any unit tests and reports both compilation and test errors.

MobileAppHarbor is an impressive mobile-optimized HTML client that uses almost all aspects of the API. We're keen on making appharbor.com work on more devices and MobileAppHarbor does a great job of showing what's possible. We're also happy to see that the API is complete enough to duplicate most aspects of appharbor.com in a client that uses the API.

As mentioned in the contest announcement the winners get to pick between a new iPad, a 27" Apple display and a Xbox in the order they placed in the contest. We're contacting the winners to figure out who gets what.

Please don't stop building stuff on the AppHarbor API, we're excited about the possibilities and we'd love to profile more great API-using apps on the blog. For inspiration, check out some of the great open source code already out there: AppHarbify, AppHarbor.NET and the AppHarbor command line interface.