Brain  Crist

Brain Crist

1597024800

New experimental Razor editor for Visual Studio

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:
  3. Enable new experimental Razor editor
  4. 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!");
</script>

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!

#aspnetcore #visual studio code #visual studio #code

What is GEEK

Buddha Community

New experimental Razor editor for Visual Studio
Brain  Crist

Brain Crist

1597024800

New experimental Razor editor for Visual Studio

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:
  3. Enable new experimental Razor editor
  4. 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!");
</script>

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!

#aspnetcore #visual studio code #visual studio #code

Juanita  Apio

Juanita Apio

1618243440

[Guest post] Learn C# with Visual Studio, Visual Studio for Mac, and Unity

UPDATE: The book giveaway challenge is complete. We will be announcing winners on the Visual Studio blog within the next week. Thank you for your submissions!

Visual Studio is an amazing development tool. But Visual Studio and Visual Studio for Mac are more than just intuitive, state-of-the-art development environments. They’re also remarkably powerful learning and exploration tools, with features to help you create and understand your code. I love teaching and learning about C## with Visual Studio. That’s why my co-author, Jenny Greene, and I put Visual Studio and Visual Studio for Mac right at the center of our latest book, _Head First C# _(4th edition), published by O’Reilly Media. _Head First C# _incorporates Visual Studio directly in the learning. combining Visual Studio with the unique and innovative “brain-friendly” Head First approach to teaching helps us make learning C## easier and more fun for our readers.

#visual studio #c# #unity #visual studio 2019 for mac #visual studio for mac

Brain  Crist

Brain Crist

1595337660

Visual Studio 2019 v16.7 Preview 2 Available Today!

C++ Updates

Visual Studio v16.7 Preview 2 delivers various improvements in the C++ space. Within the Connection Manager, you’re now able to edit remote SSH connections, e.g. if the IP address of your target system changes and needs to be updated. You’re also able to set default remote connections to be consumed via **${defaultRemoteMachineName} **in CMakeSettings.json and launch.vs.json.

When you edit a remote connection, Visual Studio will no longer need to recopy headers to Windows for a native IntelliSense experience. Likewise, setting default remote connections is useful for checking CMakeSettings.json and launch.vs.json into source control with no user or machine-specific information. These remote connections over SSH allow you to build and debug your C++ projects on a remote Linux system directly from Visual Studio.

CPP Add or Remove SSH Connections

C++ Add or Remove SSH Connections with Connection Manager

This release also brings enhanced IntelliSense support for Clang on Windows (clang-cl) in Visual Studio. The clang include path now includes the clang libraries, we’ve improved the display of in-editor squiggles (particularly when using the std library), and we’ve added support for C++2a is supported in clang mode.

The Preview release also contains four new code analysis rules to incorporate additional safety features into C++: C26817C26818C26819, and C26820. Please see the C++ Team Blog for more info.

In addition, new C++20 Standard Library features have been implemented. A detailed list is provided in the STL Changelog on GitHub.

.NET Productivity

Quick Info now displays the diagnostic ID along with a help link where you can easily navigate to our documentation to learn more about warnings and errors in your code.

Diagnostic ID with help links in .NET Productivity

Diagnostic ID with help links in .NET Productivity

Git Productivity

We continue to release more Git functionality in Visual Studio 2019. This time we focus on merge conflict resolution. We’ve revamped the Visual Studio merge editor by decoupling it from TFVC and focusing it on Git.

A new gold info bar at the top of a file will tell you when there are merge conflicts that need to be manually resolved. Clicking will take you to the merge editor, which now has more informative tiles and captions to help you distinguish between the conflicting branches. We’ve reduced the clutter around the zoom margin, health margin, and the toolbar. In addition, it is easier to parse conflicts with aligned matching lines, word level differences, and visible whitespace when it is the only difference. You can turn off non-conflicting differences to just focus on the conflicts. You can also resolve add/add conflicts at the file level now with a two-way merge. Finally, we have added a checkbox to resolve all conflicts on one side or the other with a single click.

Try the new features by toggling the Preview Feature for New Git user experience in Tools > Options.

Improved Git Functionality in Visual Studio 2019 under the Tools Menu

Improved Git Functionality in Visual Studio 2019 under the Tools Menu

In other Git improvements, we will now close any open folders or solutions before starting a new clone operation, so that Visual Studio can open the newly cloned repo to help you get to your code faster. We’ve improved upon the commit text box, adding inline error checking. And we’ve added UI to help you more clearly understand what is happening when you initialize and push a repository to a remote host like GitHub or Azure Repos.

Local Process with Kubernetes

Local Process with Kubernetes allows you to write, test and debug your .NET code on your development workstation while connected to your Kubernetes cluster with the rest of your application or services. By connecting your development workstation to your cluster, you eliminate the need to manually run and configure dependent services on your development machine. Environment variables, connection strings and volumes from the cluster are available to your microservice code running locally.

For more information on Local Process with Kubernetes, we have detailed it out in our team blog.

#visual studio #announcement #visual studio 2019 #visual studio code

Brain  Crist

Brain Crist

1596975120

Writing Visual Studio Extensions with Mads - Episode 1: Item Templates

Join Mads Kristensen from the Visual Studio team each week as he builds extensions for Visual Studio live!

#visual studio code #visual studio #code #microsoft #visual studio extensions

Brain  Crist

Brain Crist

1596991620

Reporting Exceptions Well in Visual Studio

Microsoft has some “best practice” advice to share on how to handle exceptions (a topic I’ve discussed elsewhere). The Microsoft article is well worth reading … but there’s one piece of advice that I disagree with (talk about hubris, eh?).

One of Microsoft’s recommended practices is that you should prefer to throw a built-in Exception class rather than your own, custom Exception class. The problem I see with this is that the built-in Exception objects return, at best, the technical reason for the exception (for example, “Division by zero”). Creating your own exception object allows you to specify the business reason for the failure (for example, “Customer has no sales orders”).

Personally, I think that the message with the business reason is more useful both to the user faced with the message and the developer who has to fix the problem. Instead, I recommend using a custom exception object and tucking the original Exception into your custom Exception object’s InnerException property. That gives you the best of both worlds.

#visual studio code #visual studio #code #new