.NET on Linux: Which Environment?

If you are a Windows developer and you want to start writing .NET code in Linux, and you’re not sure where to start, this article should help you understand some of the choices regarding your development environment.

I’ll be using the Red Hat Enterprise Linux Developer Suite (RHEL) as my Linux of choice, which is freely downloadable for development use. It’s also worth mentioning that how you actually install RHEL will affect your development experience. The up-front work to get a full-blown, GUI-based version of RHEL running is, I believe, worth the payoff later. However, you may choose to get up and running quickly in a command line environment and defer the GUI work until later.

Some of your choices include:

  • Run RHEL on bare metal. That is, install it directly onto a PC. You can choose this option and run with or without a graphical interface (such as Gnome).
  • Run RHEL locally using a hypervisor/virtual machine (Hyper-V, VirtualBox, VMware) on your Windows environment. This requires that your version of Windows supports virtualization (e.g. Windows 10 Professional). You can choose this and run without a GUI. Alternatively, you can install a GUI, which is what I recommend — more about that later.
  • Finally, you could use a cloud-based VM running RHEL (Typically no GUI).

RHEL on Bare Metal

If you choose to install RHEL on bare metal, you’re most likely going to want to use Gnome for a GUI. That will allow you to also run Visual Studio Code (VSCode) – Microsoft’s free code editor (based on Electron). This option offers the best performance, but it does mean you need a physical machine. This configuration basically involves installing RHEL from the ISO file and going from there. In this scenario, you’re living and working in Linux. You can edit and debug your code from within the IDE (VSCode) and you won’t need to install a lot of supporting software – pretty much everything you need will be in one place: inside RHEL. You may, however, end up lugging around two notebooks PCs, or setting up a “dual boot” environment on your single machine.

RHEL in a Virtual Machine

Running a Virtual Machine (VM), whether on you are on a local PC or in the cloud, gives you the option of choosing between a command line or a GUI. It also means you can leave your Windows PC alone. You can run RHEL simply as a console (i.e. you open a bash shell terminal on your Windows PC), or as a desktop, using VNC to connect. Let’s explore these two options a little.

Headless (No GUI)

Running RHEL without a GUI (“headless”) means you’ll need a bash shell on your Windows machine. Microsoft has made this available now (it’s a beta), or you can use a third party solution such as Cygwin. This isn’t a bad thing, because you can start to use the bash shell for all your command-line operations, even against  your Windows file system. You benefit in that you learn bash and use it everywhere.

Running headless also means you’ll probably edit your code on your Windows PC and then either save then in a folder that is shared between the host and the VM. You can also use a git repositoryto push code from your Windows PC and pull from the VM via the bash command line. Lastly, as I explain in a recent blog post, you can set up direct filesystem sharing using Samba (this is the most work to set up, but the least work go use). The biggest limitation? You won’t be able to debug your code from within VSCode. That’s a big deal if you ask me. In fact, I consider it a show-stopper. (And I’ll explain how to get that working in a future blog post.)

With GUI

Running RHEL with a GUI, especially in a VM on your local Windows PC, is a full-feature environment. You use one PC. You keep Windows. Best of all, you can run VSCode on Linux, which means you can debug your code from within your IDE. You can set breakpoints, inspect variables, see the stack trace … everything you need for a full-featured interactive debugging session. There are some considerations, however.

If you’re using Hyper-V, you’ll likely want to install the VNC server on your RHEL VM, and install the corresponding VNC client on Windows. This is due to the fact that changing screen resolutions on Hyper-V can prove difficult or impossible. (This issue does not occur with some of the other VM technologies listed above.)

I use TightVNC on Windows, and it works very well. You’ll also want to use Cygwin to SSH into your VM and run common commands from the command line. For example, yeoman and Autorest are both command line tools that you’ll probably want to use.

For me, being able to summon my RHEL environment with a few mouse clicks and enjoy the rich, feature-laden experience of coding and debugging from the IDE makes this the best option.

Conclusion

No matter which environment you choose, you’ll be well on your way to creating .NET code that can almost anywhere, including Linux. Get started now by downloading your developer’s copy of RHEL and setting up your environment.

Additional Resources:

.NET on RHEL Webinar (video)

Red Hat Enterprise Linux Developer Suite

Linux commands cheat sheet

Red Hat Developer’s site for .NET

Visual Studio Code

Cywin bash shell for Windows

TightVNC for Windows

Microsoft’s .NET site


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

 

Take advantage of your Red Hat Developers membership and download RHEL today at no cost.

Share

  1. The Get Started guide for Red Hat Enterprise Linux covers installation on bare metal, Hyper-V, VirtualBox and VMware. All four paths install a full graphical desktop based upon GNOME 3 which is the default for Red Hat Enterprise Linux 7.

    http://developers.redhat.com/products/rhel/get-started/

    Note: There is really isn’t a need to choose at install time between “headless (no GUI)” and “With GUI” for your VM, you can have both and choose between them based on the task at hand. If you configure your VM’s network configuration to use something other than NAT, you can ssh into your VM using any ssh client (Cygwin, Putty, MSYS, or the beta Windows 10 subsystem for Linux.)

Leave a Reply