At work we’ve made the jump from back-end coding in Visual Studio and running our APIs on Windows with IIS to coding and hosting everything on Linux. We also switched from SQL Server to Postgresql. It took several months to complete the transition in steps, but we’re almost there. It can be done.

I Know What You’re Thinking

You’re thinking that you could never give up the luxury of Visual Studio. You could never survive without the convenience of Intellisense and autocomplete. Your life would be meaningless without your precious breakpoints and line-by-line debugging. You would shrivel up into a dry empty husk in the absence of ReSharper’s loving embrace.

Life with C# on Linux isn’t all that bad. You can still have many of the things you love about Visual Studio, without all of the bloat. The purpose of this article is to explain how I’ve achieved some of that for myself.

Why Make the Switch?

The reasons for phasing Windows and Windows-based tools out of our tech stack can, if you ask me (which you implicitly have by reading this article) be boiled down to “Windows sucks.” The primary motivating factor is that automatically provisioning Windows machines (being able to consistently spin up new instances and get your software and its dependencies installed and configured) is like trying to train a cat to use a human toilet. Sure, it can be done (I’ve seen videos), but it’s difficult, it’s unnatural, and people will think you’re not right in the head for even trying. The fact that Windows servers are typically more expensive (almost comically so when dealing with SQL Server) doesn’t help. Linux is just a cleaner solution for running server infrastructure. Microsoft is certainly headed in the right direction these days, and I have some confidence that they’ll get there eventually, but as it stands today Windows sucks as a server platform.

Windows Server 2012 uses their touch-screen optimized GUI, for goodness’ sake! Who thought that was a good idea? A server operating system doesn’t need a GUI to begin with let alone a poorly conceived tablet-optimized one.

In theory, even if you’re running your production environment on Linux and Mono, you could still choose to develop in Windows and Visual Studio—in my experience, situations in which you need to write code differently between the two platforms are pretty rare and easily avoided. There have been situations we’ve run into where Mono behaves slightly differently (usually in unexpected or broken ways), so if you take this approach it’s possible that you might miss problems with your code that exist in Mono but not Windows, so it’s important to write lots of tests and to run them using Mono prior to deploying.

I am a huge fan of Vim. When I was coding in Visual Studio I was using an extension called ViEmu which added Vim keybindings and features to the editor. The problem with ViEmu is it’s freakin’ expensive. I think I paid $100 up front for a license and then had to re-up my “subscription” a couple times for $50 when new versions of Visual Studio came out in order to get a new compatible version of the extension. I certainly don’t begrudge ViEmu’s creator for making money off his work, but paying hundreds of dollars to use features from a free open-source editor makes baby pandas cry. Add to that the cost of Visual Studio itself plus another “subscription” to ReSharper and you’re starting to reach levels of expense that simply don’t make sense for a solo indie developer (yes, I do this in my day job, but I don’t use the tools they provide for my personal/hobby work on the side). Visual Studio is also slow.

C# Autocomplete in Linux

The simplest option to get intellisense-like autocomplete functionality on Linux is to use MonoDevelop (or Xamarin Studio if you’re on OS X). Meet the new boss, same as the old boss. If you’re happy with a big all-encompassing development environment like this, more power to you! Heck, why not go one step further and use Visual Studio Code?

If you prefer to use your editor of choice (Emacs, Vim, Atom, etc.), you can probably also have autocomplete, it’s just a little more complicated to set up.

Omnisharp and Friends

Omnisharp is a mish-mash of open source stuff that adds .NET tooling to a variety of editors on Linux. For Vim, use your preferred plugin manager to install the Omnisharp-vim plugin. The readme covers the configuration changes and build process required. You will also need to install an autocomplete plugin—there are a few options listed in the readme but the one that I was able to get working is YouCompleteMe. Just make sure to include the --omnisharp-completer argument when running the install script.

I also installed dispatch.vim which will automatically enable the .NET tooling in Vim whenever you open a C# source file. If you didn’t install this, you’d need to manually start up the Omnisharp server and connect to it whenever you want your autocomplete. One downside of the automated method is that you can’t edit files from two separate solutions at the same time. Omnisharp runs as a server that parses your solution and project files, and the autocomplete plugins get their information by querying that server process, which means once that process is started for one solution, opening files from another solution will try to use autocomplete information from the first one. In theory you could work on multiple solutions simultaneously, but it would require manually spinning up and connecting to multiple instances of Omnisharp running on different ports.

Another nice benefit of Omnisharp-vim is that whenever you edit and save a new file, it will traverse up the directory tree and add that file to the first project it finds. That’s handy, but you still end up needing to manually modify csproj files in a lot of situations (adding or updating references, removing or renaming source files, etc.). If there’s something particularly tedious I need to do along these lines, I usually cave in and spin up a copy of MonoDevelop. I would, for example, want to gouge my own eyes out with a rusty spoon if I had to manually update a Nuget package across a couple dozen projects.

Debugging

If you want line-by-line debugging with breakpoints and watches and all that other stuff that you’ve probably become so dependent on in Visual Studio, your only options are MonoDevelop/Xamarin Studio or Visual Studio Code. Personally, I’ve eschewed debugging since making the move to Linux, relying instead on console output and throwing exceptions in my code to help track down tricky issues. At first I thought that this would be a deal breaker, but after several weeks I’ve found that it’s actually not that bad. Being able to set breakpoints and do line-by-line debugging isn’t as important as you think once you get used to life without them.

Testing

Visual Studio has some pretty nice test-running facilities built in. We use Xunit for all of our testing, so I would run all of our tests using the ReSharper Xunit runner. Now I run them all from the command line using the Xunit console runner. Works fine.

One gotcha to be aware of is that if you’re using Xunit 2.0, it doesn’t work in the current version of Mono. There is an outstanding issue in Xunit, but it’s actually due to a bug in Mono. The bug has been fixed, but we won’t be seeing it until Mono 4.2 is released. I have no idea when that will be (as of this writing Mono is at 4.0.3). Fortunately, we were still on Xunit 1.9 when we made the switch, so our tests run fine.

Continuous Integration

I’m going to get really esoteric here and talk about using Shippable to build Mono projects. Don’t do it! It is an exercise in frustration and futility. Something about their setup (which may actually be a larger issue with running Mono in Ubuntu in general) makes Mono unusable. You can read about some of my trials and tribulations in the issue I opened.

Conclusion

This article is a lot more rambly than I had intended, but hopefully I’ve achieved my goal of portraying the current state of working with .NET and C# in Linux as pretty far along—certainly far enough to work competently and comfortably on serious projects. We’re still finding new little bugs and issues in the Mono runtime itself that we have to work around, but no show-stoppers, and things are only going to continue to improve now that Microsoft has open-sourced the .NET runtime.