Hi OrchestraMusic, Welcome to the MSDN forum. Now we have two Visual Studio versions (Visual Studio for Mac, Visual Studio Code) that can directly install on the Mac (macOS), refer to your description, it looks like you installed the Visual Studio for Mac, it is a developer environment optimized for building mobile and cloud apps with Xamarin and.NET. We’re excited to announce that Visual Studio 2019 for Mac version 8.9 is available for you to download today.This release includes support for.NET 6 Preview 1, testing support for Unity applications, a preview of a new Quick Actions and Refactorings dialog, solution filter (.slnf file) support, and a new XML editor.

Overview

Visual Studio Tools for Unity is a free Visual Studio extension that turns Visual Studio into a powerful tool for developing cross-platform games and apps with Unity.

While the Unity editor is great for putting your game world together, you can't write your code in it. With Visual Studio Tools for Unity, you can use the familiar code editing, debugging and productivity features of Visual Studio to create editor and game scripts for your Unity project using C#, and you can debug them using Visual Studio's powerful debugging capabilities.

But Visual Studio Tools for Unity is more than that; it also has deep integration with Unity editor so that you'll spend less time switching back and forth to do simple tasks, provides Unity-specific productivity enhancements, and puts the Unity documentation at your fingertips.

Compatible with Visual Studio Community on Windows and macOS and bundled with Unity

Visual Studio and Visual Studio for Mac Community is available for free, and is bundled with Unity installs. Visit the Visual Studio Tools for Unity getting started documentation for more information about installation and setup.

IntelliSense for Unity messages

IntelliSense code-completion makes it fast and easy to implement Unity API messages like OnCollisionEnter, including their parameters.

Superior debugging

Visual Studio Tools for Unity supports the robust debugging features that you expect from Visual Studio:

• Set breakpoints, including conditional breakpoints.
• Evaluate complex expressions in the Watch window.
• Inspect and modify the value of variables and arguments.
• Drill down into complex objects and data structures.

Integrated suggestions for best practices and performance insights

Write better code that captures the best practices with Visual Studio's deep understanding of Unity projects.

CodeLens support for Unity scripts and messages

Unity scripts and message functions are decorated with hints to make it easier to recognize what's provided by Unity and what's your code.

Note

CodeLens support is available in Visual Studio 2019.

Optimized view of all your scripts to match Unity

The Unity Project Explorer (UPE) is an alternative way to view you project files over the standard Solution Explorer. The UPE filters the files shown and presents them in a hierarchy that matches Unity (View > Unity Project Explorer in Visual Studio 2019).

Note

The Unity Project Explorer is available in Visual Studio 2019. In Visual Studio for Mac, the Solution Pad has similar behaviour by default for Unity projects - no additional views are required.

We released this week the first 8.2 preview of Visual Studio for Mac. This release is important for us as it’s the first one to contain our improved editor experience for Android XML resources and Xamarin Forms XAML files both enabled by the port of the Visual Studio editor to the Mac.

You can read through the announcement above for the high-level improvements. In this post I want to focus on how we got there with specifically the Android side (I will speak about XAML in a future entry).

Now if you have read some of my previousposts, we started making heavy investment improving our editing experience for Android XML resources (originally only layout files) last year which first got delivered in the Visual Studio 2017 15.8 release and kept being improved in Visual Studio 2019.

At the time the landscape was quite different, Visual Studio for Mac and Visual Studio had only a few shared APIs (Roslyn mainly) and developing certain features (like editor extensions) required rewriting portion of the same code twice. Worse, on Windows the base XML editor that we were using as our editing canvas did not have many extensibility points.

One of the horror story of that time was around IntelliSense. Because the Visual Studio XML editor does not have an API to extend the completion list directly, we had to resort to generating on-the-fly XSD (XML Schema Definition) files that the XML language service would consume to provide the autocompletion experience.

This was alright at best with very basic elements and attributes completions but providing a comprehensive list that included all your resource references implied generating massive XSD files with a terrible performance cost.

On Visual Studio for Mac, we had the benefit of an existing and extensible XML pipeline complete with an incremental XML parser and a straightforward interface to inject our own completions depending on the caret location (elements, attributes or attributes values). This is the reason why our experience there was so much better and faster at the time.

When maintaining the previous XSD logic on Windows became untenable we went looking for other solutions. To implement an autocompletion experience at the time you had 3 possibilities:

• Use a bespoke system like the XSD files we were using (which in turn is based on a legacy Visual Studio API for language services)
• Use Roslyn editor features layer. Unfortunately this implied having an XML parser that could output Roslyn trees which we didn’t have.
• Use the low-level, MEF-based, synchronous completion API from the Visual Studio editor. This is what Roslyn would use under the hood but had extensively improved to be more asynchronous.

Fortunately for us, we asked ourselves that question right at the time when the Visual Studio editor team were developing a new more modern IntelliSense API that was async-friendly. It represented the best of both the older API (no semantic dependencies) and Roslyn (asynchronous capabilities).

We made a proof-of-concept by porting part of the Visual Studio for Mac XML service to be layered on top of this new API with great help from the editor team. The result was so much better that we decided this was the way to go. As one of the earliest adopter of this new editor feature we also (hopefully) influenced it positively (Roslyn now uses it too).

Thanks to this newfound knowledge of editor extensibility, we continued implementing more features: syntax highlighting (classification in Visual Studio jargon), semantic operations, go-to-definition and others. It came to the point that we provided enough functionality to simply drop the original XML editor altogether.

Visual Studio 2019 Mac Extensions Windows 10

We also took advantage of our other work to employ a better XML parsing pipeline in the designer itself to make the interactions between the design surface and the text editor more seamless.

Together, all those improvements switched things around and Visual Studio was now leading in terms of editor experience. We were keeping watch on Visual Studio for Mac though and we knew that, at the very least, work was on-going to provide those same editor extensibility API there to enable other teams at Microsoft to port their existing Visual Studio code over to the Mac.

As it turns out, the team decided to bite the bullet even further and ported the entireVisual Studio editor to the Mac (with its whole extensibility API coming for the ride). This was a boon for us and, from that point on, we started making sure all our Android extension code was portable across both IDEs.

What Are Visual Studio Extensions

Excitingly, we didn’t have to do much work to make this happen. Most of the available Visual Studio editor extensibility is actually cross-platform (meaning do not depend on a Visual Studio-specific API or a UI toolkit like WPF) and thus our extensions were easy to simply share in our common codebase.

(There is actually enough of that type of code aside from the WPF frontend that it was possible to create a unit-testing library with all of the open-source code available that was also shareable across both Windows and Mac)

The extensions that couldn’t be ported straightaway usually fell into two categories: they either used Visual Studio specific APIs or they referenced WPF. Here are a few example of how we solved those issues:

• For code depending on Visual Studio-specific API we looked to see why. In our case it turns out a lot of it boiled down to initializing various part of the code on-demand. Instead we moved that initialization into a single ITextViewCreationListener part that was IDE-specific and thus were able to remove the equivalent calls in our other extensions to make them agnostic.
• Another solution was to isolate the offending functionality behind another interface. We had this case with our go-to-definition service where opening a document in the IDE required platform-specific calls. What we did is hide that code behind an extremely simple interface that we could [Import] from the now shareable service and only [Export] the much smaller implementation in each IDE layers.
• One last case was where we used JoinableTaskFactory from the vs-threading library by querying it directly from Visual Studio. Rather than doing that, we simply [Import]’ed in our parts the JoinableTaskContext that is already exported by both IDEs and thus severed that dependency.
• For some extensions you may end up providing some UI adornments. In this case, you can leverage the IViewElementFactoryService API to reference a data object from the shared code and only provide the UI-specific portion in your IDE layer.
• Finally, as part of porting the editor to Cocoa, a number of public interfaces had to be de-WPF-ized and new types introduced to replace them. That work is expected to be shared back to Visual Studio but in the meantime you may have to do some creative subclassing to share functionality. A good example of this are adornment tags (think of the inline color previews in our editor).

As a testament of the hard work from the Visual Studio for Mac team to integrate the editor, we expect that by the final 8.2 release we will have ported 100% of our originally Windows-only extensions to be shared on both IDEs.

Visual Studio 2019 Mac Extensions Download

If you are yourself interested in doing that kind of work, the team has started publishing documentation. Keep an eye out for new content showing up there in the near future.