How to Run .NET on Heroku

.NET Core continues Microsoft’s shift towards a more open development philosophy. It is open-source and cross-platform. With a little bit of setup, you can get a .NET Core web app running on Linux-powered Heroku. This guide will walk you through it.

This guide is catered for development on Windows, even though the resulting web app runs on Linux via Heroku. .NET Core (the framework) is cross-platform, but Visual Studio (the IDE) is not… yet. However, there are solutions for running Visual Studio on Mac.

.NET Core and Heroku logos


Make sure you have all of the following prerequisites ready to go.

Create the Solution

Fire up Visual Studio, then go to File > New > Project.

Navigate to Installed > Templates > Visual C# (or Visual Basic, if that’s your thing) > Web. Select ASP.NET Core Web Application (.NET Core). Pick your Name (I’m using “dot-net-heroku” here) and set Location to the directory you want the solution directory to be created within. Check both Create directory for solution and Create new Git repository. Click OK to proceed.

Visual Studio new project dialog

On the next screen, select Web Application (Web API works too, if that’s what you want). Click OK.

Visual Studio template selection dialog

At this point you have a brand new solution. We’ll need to tweak it a bit, though.

Modify the Solution

Still in Visual Studio, go to View > Other Windows > Package Manager Console. This will give you a console with a PM> prompt. Execute the following command.

Now open up Program.cs for some edits. Near the top, add the following using directive.

Then update the Main() function as seen below.

Your Program.cs should look like mine. With that, the solution is ready for deployment. Now to take care of things on the Heroku side.

Create the Heroku App

Open up your command line terminal of choice and navigate to the solution directory. Make sure you’re logged into Heroku.

Create the Heroku app with whatever name you want.

Now to add the buildpack. I’ve had the best results with noliar’s fork, so that’s what I’m using here.

Finally, set up Git to deploy to Heroku and push.

Give the deployment some time to finish up, and there you have it. Go to (with your app name, obviously) and you’ll see your .NET web app running on Heroku. It should look like mine.

Chrome screenshot of a .NET Core web app running on Heroku

What you’re seeing is the default index page for the template we used. At this point you’re ready to delete the default pages and start working on your own.

Bonus: Hooking up to GitHub

You’ve got your .NET web app inside a local Git repo, but maybe now you want to add it to GitHub. Start by creating a new repo. To avoid conflicts, don’t initialize with the readme, license, or .gitignore files (you can add these later).

Creating a new GitHub repo

Back in your terminal, run these commands. Replace “your-username” and “your-repo-name” as appropriate.

If you get a pop-up about security credentials, cancel out of it and enter your credentials in the terminal.

If the terminal won’t accept your credentials, it may be because, like me, you have 2-factor authentication enabled. In this case, create a personal access token with repo access and use it in place of your password.

Closing Remarks

It’s great seeing .NET break out of its Windows-only ecosystem to embrace the more open and cross-platform community of modern web development. Also, big thanks to noliar and all the other contributors for maintaining the .NET buildpack I’m using in this guide.

Building Web Fish Daily

Web Fish Daily logo

I recently launched a new site: Web Fish Daily. It is, more or less, a curated selection of front-end web dev links, updated daily, wrapped in a simple and friendly presentation. I figured it would be a great way to stay on top of things and help others do the same. Besides that, I just had the itch to take on a new side project and play with new stuff. In that regard, huge success!


Web Fish Daily runs on KeystoneJS, which is powered by Node.js and MongoDB. In a nutshell, KeystoneJS is a CMS platform that serves as the glue holding everything together.

Setup was fairly easy. Install the prerequisite Node.js and MongoDB, run the Yeoman generator, and you’ve got a great sample app to pick apart. KeystoneJS prefers Jade and Less out of the box, but I opted for Handlebars and Sass without issue. It also comes pre-baked with Bootstrap, if that’s your thing (it was overkill for me, so I simply removed it).

KeystoneJS does a lot for you. For example, here’s the data model I use for announcements on Web Fish Daily:

From that, KeystoneJS will set up the collection in the database and give you a full admin interface (create, read, update, delete, list) to work with it. Massive time saver.

Web Fish Daily admin UI

If you need a highly customized admin UI, or multiple user accounts with different permissions, then KeystoneJS probably isn’t for you. But for basic CRUDL, the ease of development is a huge plus.


This project was all about trying new things, so I passed on the old-school shared hosting I typically use and went with OpenShift, a PaaS (platform as a service) solution.

The basic concept revolves around “gears”. You get 3 gears for free and can buy more if needed. Want to run Node.js? That’ll cost you a gear. Need MongoDB? That’s another gear. Jenkins for continuous integration? Actually, that one’s free. You can also spend gears to add memory and disk space. It’s fun in a way, but it also feels a lot more practical. You buy exactly what you want, in quantifiable pieces, with the freedom to downgrade or upgrade as needed.

OpenShift add cartridge

There’s a web interface for administering your web apps, but you also have full command line control via the OpenShift client tools. This is great for scripting tasks or automating maintenance.

OpenShift also integrates with Git, making deployment super easy. With a little help I was able to reduce my deployment process to a single command:

Other Bits

Web Fish Daily shows a live countdown for when new links will be published. Simple idea, surprisingly difficult to do. In a word: timezones. It took a lot of planning to coordinate my development machine (PST), the production server (EST), dates and times stored in the database (GMT) and visitors’ computers (could be anywhere!). I couldn’t have done it without Moment Timezone.

This is the first site I’ve made without any raster images. It’s all Font Awesome scalable vector icons, SVG, and CSS.

Big thanks to Joni Trythall for creating the fishy mascot for Web Fish Daily. It turned out great and really helped deliver the friendly vibe I was aiming for.

Thanks for reading. Follow @WebFishDaily if you want to keep in touch with the project. If you want to contribute links to be featured, send them to

Show Hidden Files In OS X

Mac OS X doesn’t show hidden files by default. That’s kind of the point of being a hidden file, after all. But sometimes you want to see them anyway. For example, if you’re looking for a .gitignore file for editing.

I thought this would be a quick fix, maybe a checkbox under System Preferences. Unfortunately, it was a bit more involved than that.

In Terminal

Probably the quickest way to see hidden files is in the terminal. Just run this:

If you want to see only hidden files, use this:

In Finder

That’s great and all, but you probably want to see hidden files as you browse in Finder. Back in the terminal, run this command:

You’ll need to restart Finder to see the change. Hold ALT and right-click on Finder in your dock. Click Relaunch. Now you’re good to go.

In Dialog Boxes

You might think that showing hidden files in Finder carries over to open/save file dialog boxes. Not so. This one’s easy though. With the dialog box open and focused, hit COMMAND+SHIFT+PERIOD. Done.

DS_Store Files Everywhere!

So now that you can see hidden files, you’ll notice something. There are hidden DS_Store files EVERYWHERE. DS_Store files (stands for desktop services store) are harmless little files that hold customization settings for folders in OS X. You can safely delete them… but they’ll keep coming back.

Fortunately, there’s a little utility out there called Asepsis. It doesn’t prevent DS_Store files from being created, but rather keeps them all tucked away in a hidden folder, significantly reducing clutter across your file system.

Asepsis is easy enough to get running. Download, install, reboot. System updates can whack Asepsis though. If that happens, run the following in terminal:

Old DS_Store Files Everywhere!

Alright, so you have the DS_Store problem solved… Mostly. Asepsis doesn’t do anything about all the DS_Store files you already had. No worries. Open up your terminal and run this one-time command to purge existing DS_Store files from your system:


Now you can see things that others can’t. Enjoy your new god-like powers.

Handy Little Script for Binding Hostnames

Where I work, I often have to bind new hostnames in my (Windows) dev environment to test different websites. This involves hunting down the hosts file, updating it, then mucking around in IIS. It can get tedious. So naturally, I asked myself if this is something I could script out. And naturally, the answer is yes.

And here it is. I call it Addhost:

I hope other people find this useful, too. Check out my Addhost repo on GitHub for documentation, updates, or if you want to fork it.