Running .NET on Heroku
Since joining Heroku I’ve been wanting to get .NET running on the platform and I’m happy to report that we now have a reasonably workable Mono buildpack. My goal was to be able to take an ASP.NET MVC solution created with Visual Studio on Windows, create a Heroku app, run
git push heroku master and have Heroku build, deploy and run the app using Mono and the XSP web server.
To use the .NET buildpack, create an ASP.NET MVC 4 web site and enable NuGet package restore. There are then a few tweaks required to make the solution palatable to Mono and xbuild (striked-out issues have been fixed in buildpack and are not necessary anymore):
- Add an assembly redirect for System.Net.Http in Web.config
Fix the all-lowercase NuGet.exe path (I believe NuGet has fixed this, but the fix is not released yet)
- Remove targetFramework attributes
Fix weird commandline argument problem in the NuGet restore command(I’ve sent a PR to NuGet)
Hopefully, we can get these obstacles eliminated through improvements to either Mono, NuGet or the buildpack.
Now, deploy to Heroku:
$ heroku create $ heroku config:add BUILDPACK_URL=https://github.com/friism/heroku-buildpack-mono/ $ git push heroku master
I’ve created a few samples that are known to work. TestingMono is an extremely simple MVC site with a background worker that logs a message once every second. To run the background worker, add a Procfile that defines the command
worker: mono WorkerTest.exe and scale it to 1 with
heroku scale worker=1. The other sample is forked from an AppHarbor sample and demonstrates simple use of a Heroku PostgreSQL database. Note that the connectionstring has to be read from the environment, not Web.config as is usual in .NET. You can find the sample running here.
Here’s what works:
- Running ASP.NET MVC 4 on top of Mono 3.0.11 and XSP 3.0.11
- NuGet package restore so you don’t have to include library dependencies in your repo
- Caching of build output and incremental builds, including caching of already-downloaded NuGet packages
- Running executables in background worker dynos
Here’s what needs love:
- Insertion of config into
- Make more of the default Visual Studio templates work out of the box
- Look for XSP replacement (likely nginx)
Also see the TODO in the README. Contributions are very welcome. I hope to cover how buildpack dependencies (Mono and XSP in this case) are generated in a future blog post.
And yes, I’m working on getting Visual Basic running.