A briefly longish tour of Visual Studio for Mac

Although I don't use Visual Studio daily anymore, I still fire it up now and again to try something out or help with a project. It's a great IDE that's had a few hiccups along the way, but has steadily gotten better. It's a powerful tool for .NET developers, and given that I currently use Atom to develop Erlang I'd give anything for an equivalent IDE. But since I use a Mac primarily, using Visual Studio means firing up Windows in a VM, which is a phenomenal way to turn a Mac into a personal space heater.

So when Microsoft announced the release of Visual Studio for Mac a couple weeks ago, I had to try it out. "Visual Studio" and "Mac" were two things I never thought I'd hear together. (Note that this is separate from Visual Studio Code, an editor more similar to Atom or Sublime than a full IDE.)

A Brief History

When Microsoft introduced the .NET Framework in 2000, they built it against a standard they helped develop called the Common Language Infrastructure (CLI). When some developers wanted something similar to .NET for other systems, they built a new project called Mono to the CLI standard as well.

Years later, after Mono was acquired by another company, the same dev who started it (Miguel de Icaza) created a company called Xamarin that went on to produce a bunch of cross-platform tools for developing mobile apps and stuff. Funnily enough, the company that bought Mono didn't seem to do much with it and he ended up supporting it again. Xamarin got bought out by Microsoft, who hired Miguel and rolled the various Xamarin apps into Visual Studio.

Built on Mono and Xamarin Studio, Visual Studio for Mac was previewed in Nov 2016 and officially released in May 2017. It uses the Roslyn compiler for intellisense and refactoring, and the MSBuild build engine.

Getting Started

Check out the minimum system requirements and then go to the download page.

The installation was pretty straight-forward except that it required I download Xcode too. I imagine a lot of developers using a Mac might already have it, but I didn't. I've found it to be buggy in the past... I can't remember the exact issue I was having but it was something weird about the license and popup reminders and having to run stuff at the command line that kinda fixed it but not really, so I had just uninstalled it. We'll see if it behaves this time.

There are some separate SDKs you can install to support other types of projects too, but you don't need those right away.

First Impressions

So far, from what I've read, two things are true about Visual Studio for Mac. First, it's built as a native Mac app from the ground up, so it shouldn't look like a Windows app shoehorned into macOS. That would have been just ugly. Second, it's built with VS (for Windows) in mind, so the experience should be very similar for devs moving from one to the other.

The latter seems pretty important to me. A familiar interface will drive adoption from traditional Windows users who now use Mac. Since I've used VS for nearly a decade on Windows, but I've been using a Mac nearly exclusively for the last 18 months, I think I'll have a good feel for both.

The Welcome Screen

Firing up VS for Mac for the first time, it definitely feels like a native Mac app. It also feels very crisp and responds quickly. The Mac I'm using is an i7 with 16 GB RAM so ymmv, but it certainly seems to respond well.

Here's a view from Windows and then macOS.

There's a lot to compare even here.

  • They both have a "Get Started" section with links to tutorials and documentation.
  • They both have a list of recent projects to choose from.
  • There's a panel with recent developer news.
  • In the upper-right corner, you can see they implemented the global search in the Mac too that makes it easy to find commands, menu items, etc without having to dig through everything. Nice!
  • The menu is integrated in the normal macOS way, pinned to the top of the screen and not in the application, but the layout looks very similar to the Windows version. So far so good.
  • Organization of available project types is different.
    • The Windows version organizes first by language, then by project type.
    • The Mac version organizes by project type, then provides a small drop-down that lets you choose the language. The available languages for now are C# and (limited to certain projects) F#, IL and VB.NET.

Let's Try a Console App

Creating a "Hello World" console app is about as simple as it gets in Visual Studio, so we'll try that in both versions and compare the experience.

Windows

Go to File / New / Project / Visual C# / Console App (.NET Framework) and you'll get the following template:

using System;  
using System.Collections.Generic;  
using System.Linq;  
using System.Text;  
using System.Threading.Tasks;

namespace vs4win_console1_netframework  
{
    class Program
    {
        static void Main(string[] args)
        {
        }
    }
}

Mac

Go to File / New Solution / Other .NET / Console Project and you'll get a very similar template.

using System;

namespace vs4mac_console1  
{
    class MainClass
    {
        public static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

There's a slight difference in behavior that's interesting. The Mac console displays the above line of code, then "Press any key to continue..." and waits for the user.

In a Windows console app you have to explicitly write that line:

Console.WriteLine("Hello World!");  
Console.WriteLine("\r\nPress any key to continue...");  
Console.ReadLine();  

When I opened the code from macOS in Windows, it ran just fine. When I opened the code from Windows in macOS, it wouldn't run. No error, the app just flickered like it was trying but then.. didn't. I assume it's because the app I created in Windows wasn't targeting .NET Core, which is a special version of the .NET Framework that should be able to run across platforms.

So I created a .NET Core Console App in Windows and tried opening that in the Mac. It made me download the .NET Core SDK (and OpenSSL too, though I'm unsure why). I tried to run it again but got a prompt "An admin user name and password is required to enter Developer Mode." which seems to be an Xcode thing. After I did, Mac ran the .NET Core app created on Windows, so that's awesome.

Now Let's Try a Library

Next I created a library on the Mac to see if the DLL assembly it produced could be shared with Windows as long as we're using .NET Core.

On the Mac: File / New Solution / .NET Core / Library / .NET Standard Library

Here's a ridiculous method courtesy of xkcd.

namespace vs4mac_dotnet_standard_library  
{
    public static class Magicmatics
    {
        public static int GimmeRandomNumber()
        {
            return 4;  // chosen by fair dice roll.
                       // guaranteed to be random.
        }
    }
}

Now I can open the previous console app on the Mac and try using the DLL produced by building the above library. Once I added a reference to the DLL (right-click "References", select "Edit References", and find the DLL in that project's bin/debug folder on disk), I was able to use it but the IDE was underlining my code and telling me I needed to include a reference to System.Runtime, which doesn't seem to exist by itself in the "references" window.

To fix that issue, I had to add a package (right-click Packages and select "Add Packages"), then search for and add "NETStandard.Library" which is the same package in the "library" project. That added a whole lot of core references like System.Runtime, System.Linq, System.Collections, etc. Now it works and I'm able to do this:

using System;  
using vs4mac_dotnet_standard_library;

namespace vs4mac_console1  
{
    class MainClass
    {
        public static void Main(string[] args)
        {
            var randomNumber = Magicmatics.GimmeRandomNumber();

            Console.WriteLine($"Hello World! Your random number is: {randomNumber}");
        }
    }
}

The only other thing I'm curious about is whether this library can be used directly from VS Windows too, without having to rebuild the project. I copied the DLL to the Windows machine and tried referencing it from a Windows app. It worked straight away!

Features

Okay, time to bring this home but let's check out a couple popular features first.

Intellisense

It feels a little bit different, but intellisense appears to be present and accounted for. The interface is clean and easy to read, and you can use the arrow keys to scroll through a method's available overloads.

Static Analysis

As I was typing these short examples, the IDE was underlining code it wanted to point out for various reasons. It usually provided options for me to choose from too, like adding the static modifier to the class.

Something I really like is how it shows you what the code will look like. Visual Studio has, for a few years now, been more focused on presenting things to the developer inline, instead of making you click around and get popups and leave the current screen. So it's a nice touch that even before I applied the suggested fix (seen below) it was showing me how my code will be modified.

A Few Issues...

There were a few snags while I was playing around, which isn't surprising considering this just came out a couple weeks ago, but maybe listing them here will save someone else's time.

Where's the Code Folding?

It's nice to be able to fold a block of code and get it out of the way. It didn't appear to be in Visual Studio for Mac though! That seemed like a strange omission to me, but it turns out the option is just disabled by default. Go into the "preferences" panel to enable it. Maybe they're not confident about this feature yet? Or do they figure Mac users wouldn't use it?

Crashing Templates

There's a nice toolbox on the side, at least with the project types I tried out, that provides some templates you can drop in. When I tried to use the Exception template that provides the barebones class for you to derive your own custom Exception, the app just crashed. When I reopened, VS recovered the document and the template was there, but the initial adding of it crashes the app every time. I'll have to see if anyone's reported this issue yet.

One Solution at a Time

You can't open multiple solutions in separate windows. The Mac loads an app in a single instance, an incredibly annoying experience because even when an app allows for multiple "windows", like Google Chrome, you can't just command-tab through the windows - it just picks the last one that was active.

Instead you have to jump through a few hoops to load more than one solution:

Open your first solution. Then go to File / Open and select the second, but don't open it yet! Click the Options button to get a few more selections, one of which is a checkbox to "Close current workspace". Uncheck that.

Then you'll see multiple solutions in the same window:

But none of these issues are major ones... just a few kinks to work out and some UX to get used to (for someone used to using Visual Studio in a Windows environment).

Highlights

There are all kinds of other things to try out and so far I've just scratched the surface, but this post is long enough already.

Here are some other things I'd like to check out in the future:

  • Experiment with cross-platform Xamarin.Forms UI library
  • Libraries available via NuGet
  • Testing, try out the XUnit project type, test out NUnit too
  • Try existing extensions like NDepend or ReSharper
  • Try more C# 7 features, and F# too
  • Play around with tying an app into Azure for the backend

Learn More

For more reading, here's a list of articles I found:

Even More

Videos

If you want to see any of the code snippets I wrote above, they're also available on GitHub.


Subscribe to Weekly Updates!

Get an email with the latest posts, once per week...
* indicates required