New experimental Razor editor for Visual Studio

Daniel Roth

With the release of Visual Studio 2019 16.7 Preview 4, you can now try out our new experimental Razor editor for local development with MVC, Razor Pages, and Blazor. We’re excited for you to give it a try!

Enabling the new Razor editor

To enable the new experimental Razor editor in Visual Studio 2019 16.7 Preview 4 or later:

  1. Install the latest Visual Studio preview
  2. Go to Tools > Options > Environment > Preview Features and select the Enable experimental Razor editor option:

    Enable new experimental Razor editor

  3. Select OK and restart Visual Studio

That’s it! You’re now setup to use the new Razor editor when working with Razor files locally (.cshtml and .razor).

What is Razor?

Razor is a templating language based on HTML and C# used to define dynamic rendering logic for .NET web apps based on MVC, Razor Pages, and Blazor. In MVC and Razor Pages apps you use Razor to define the rendering logic for your views and pages using .cshtml files. In Blazor, you use Razor to author reusable UI components in .razor files. Razor is a critical part of the experience for building web apps with .NET.

You can give Razor a try today by building your first web app with ASP.NET Core or Blazor.

Why a new Razor editor?

Part of the value of Razor is the rich tooling experience Visual Studio provides for editing Razor files. Visual Studio today provides IntelliSense, completions, and diagnostics for HTML, CSS, JavaScript, C#, and Razor specific syntax all within the same Razor file.

Visual Studio does some tricky gymnastics to enable editor support for all of these languages at the same time in Razor files. The Razor document is parsed to determine its constituent parts, and then each part is projected into a language specific buffer called a projection buffer. What you see in Visual Studio when editing a Razor document are a collection of little windows into each of these projection buffers to make up one whole document. Each language service then independently handles the editing experiences for each of these separate projection buffers.

For example, consider the following Razor code:

    ViewData["Title"] = "About";
<script type="text/javascript">
    alert("Hello, World!");

The way Visual Studio handles this Razor code looks something like this:

Razor editor architecture

This project buffer setup works well for Visual Studio and Visual Studio for Mac, but it’s problematic for remote editing scenarios, like Visual Studio LiveShare or Visual Studio Codespaces. It also can’t be used for editors that don’t have projection buffer support, like Visual Studio Code. The lack of a central orchestrator for the Razor editor also makes it difficult to enable new features without careful coordination between the various language service implementations (since they each control their own experience in projected scenarios).

A Razor Language Server

To enable broader support for Razor editing, we have been working for some time on a new Razor editor for ASP.NET Core projects based on a Razor Language Server. This new Razor Language Server implements editor features like auto completion, go to definition, etc. through the Language Server Protocol (LSP), which defines a standard way for an editor or IDE to enable these features. An IDE specific Razor extension then handles coordinating with the Razor Language Server and the other language servers for HTML & C#.

LSP Razor editor architecture

This new Razor Language Server is already being used to enable Razor support in Visual Studio Code as part of the C# extension. It will be the basis for the Razor editing support in Visual Studio Codespaces and Visual Studio LiveShare. And now it is available for local development in Visual Studio as a preview feature.

Currently our focus has been on making the new LSP based Razor editor have functional parity with the existing Visual Studio Razor editing experience (as noted below, there are still a few functional gaps to address). In future releases we expect to fill these functional gaps add significant new functionality, like bringing many more of the C# editing features to Razor, and enabling other new Razor specific productivity improvements.

Known issues

The new Razor editor is currently experimental and has some known limitations. The following Razor editor features have not yet been fully implemented and will be added in a future release:

  • JavaScript and CSS IntelliSense support
  • Colorization for C#, JavaScript, CSS, Blazor components, Tag Helpers, and tooltips
  • Formatting is limited to only C# code in @code and @functions blocks with no embedded HTML markup or Razor syntax
  • URL picker support in HTML
  • C# snippets (‘prop’, ‘ctor’, etc.)
  • Complex C# completions (for example, generating overrides)
  • Go-to-definition/implementation from C# to Razor
  • Renames in C# files do not propagate to Razor files
  • Matching identifier highlight support for HTML and curly braces

There are also some functional issues with the new Razor editor in 16.7 Preview 4 that will be addressed in a future release:

  • C# error squiggles may be misaligned
  • Unnecessary informational errors reported for unnecessary using directives in Razor files
  • Blazor components & Tag Helpers are currently colored like C# classes and don’t respect the Tag Helper colorization option

Give feedback

These are still the early days for the new LSP-based Razor editing experience in Visual Studio. We know that there’s still a lot of work to do before it can replace the existing Razor editing experience in Visual Studio. The new Razor tooling will remain optional and experimental in 16.7 and we don’t expect to make it the default Razor editor until it surpasses the functionality of the existing editor. But, we wanted to share our progress as early as possible to start getting your feedback on how well the new Razor editor works for you. To ensure we ship the best Razor editing experience possible, please give the new Razor tooling a try and let us know what you think. You can share your feedback with us by creating Razor Tooling issues on Github in the ASP.NET Core repo. We appreciate your feedback!