Introducing the new Razor editor in Visual Studio 2022

15 comments

Comments are closed. Login to edit/delete your existing comments

• 

  Muhammad Miftah December 1, 2021 3:26 pm 0

  collapse this comment copy link to this comment

  Razor syntax, much like XAML, I think were reasonable inventions for their time. But after years using WebForms + jQuery, then MVC + Razor, WPF & Xamarin with XAML and more recently, React + JSX (and then later on with TypeScript as TSX), I have to say JSX/TSX blows them all out of the water; it’s probably the golden standard when it comes to developing views and the ensuing logic that comes with rendering them (whether it’s targeting web or any other platform).

  Having a HTML-like markup dialect directly integrated into the language makes the experience so much more fluid and intuitive; yeah Razor is way batter than what we had with WebForms, but it still doesn’t quite reach the same level as JSX/TSX does.

  Please look into implementing a C# equivalent of JSX/TSX! (call it ‘CSX’ perhaps?) Microsoft could, in one fell swoop, provide a truly modern programming experience for writing views with C#, and it could also replace both Razor and XAML at the same time, making it suitable for both web and mobile development!

  • 

    John King December 1, 2021 5:16 pm 0

    collapse this comment copy link to this comment

    Jsx/Tsx doesn’t work in a full strong type world and Razor is the implement for strong type!
    I’m think we should investigate with the Angular lvy Template and improve Xaml. lvy is full strong typed

       lvy concept                      |                xaml concept
     |-----------------------------|----------------------------------------------|
    one way binding [attr]="value"   |  one way binding :{bind path} 
    two way binding [(attr)]="value"  |   two way binding :{bind path, BindModel=TowWay} 
    event : (event)="handler"             |   event  :  event="handler"  
     direct reference  with  #name or #name="Type" |    direct reference with x:Name="name"  
    value  reference  with direct  assign   |     DataContext + binding path  
     ngFor    (allow with Obserable)  |  childe binding + Obserable 
    ngIf                                            |  C# code or TempalteSelectAdapter 
    Directive                                   |     extend property 
    type check                               |   none 
     analysis visual tree without run |    analysis visual tree without run
      
    
         none（use event instead）    |   command binding 

    use ivy should have better performance because there no `reflation` and can be full AOT with Source Generator (direct reference)

• 

  Mladen Mihajlovic December 2, 2021 12:10 am 0

  collapse this comment copy link to this comment

  If this is running as an LSP then will omnisharp and vscode be getting this functionality soon? I don’t see any mention of it…

  • 

    Jacob McDowell December 2, 2021 6:05 am 0

    collapse this comment copy link to this comment

    Hey, fellow VS Code user here. Most of this is/has been working for me. Certain things are hit or miss, but it’s mostly there. A couple thoughts:

    First, some settings – idk if any in particular are needed for this, but it’s worth a shot:

    “omnisharp.enableImportCompletion”: true,
    “omnisharp.enableRoslynAnalyzers”: true,
    “omnisharp.path”: “latest”,

    Also – i imagine the percentage of Windows VS Code users who *don’t* use Visual Studio at all is pretty slim, but i’ll toss it out – OmniSharp will use Visual Studio bits if they’re installed. IDK if it’s better than a vanilla SDK install or relevant to the Razor LSP whatnot but if you’re on Windows but without a Visual Studio install, it may be a different experience.

    • 

      Mika Dumont December 2, 2021 11:42 am 0

      collapse this comment copy link to this comment

      At present we’re working on ensuring where most of our .NET developers are in Visual Studio have great experience. Having a reliable experience in VS Code for C# development is also important to us and we’re looking at ways to improve the reliability with the VS Code extension and OmniSharp.

• 

  Matt Beckius December 2, 2021 6:45 am 0

  collapse this comment copy link to this comment

  Is goto definition (F12) supposed to work for navigating to other Razor components? R# has had the feature for Blazor for ages now.

  • 

    N. Taylor Mullen December 2, 2021 8:28 am 0

    collapse this comment copy link to this comment

    Yes!

• 

  MgSam December 2, 2021 7:36 am 0

  collapse this comment copy link to this comment

  Not directly related to your editor, but if it’s easier to hook into now I humbly suggest finally moving T4 templates over to Razor syntax (another request which people have been asking for for 10 years 🙂 T4 is so similar to what Razor already does that it is crazy that they remain different techs.

• 

  Shannon Slaton December 2, 2021 11:32 am 0

  collapse this comment copy link to this comment

  I have a rather large Blazor WASM project. I just migrated to Net 6 and I am running VS 2022 17.0.2. When I run my project it seems a lot faster which is good, but currently trying to edit the code is a painful experience. Sometimes I type a letter and it locks up. Sometimes running the debugger can take twenty minutes to load the project. Of course Hot Reload doesn’t work. The intellisense takes forever to popup. Everything takes forever. Constantly it goes gray and doesn’t respond for a few minutes. I am at a complete loss as to what to do. It is so buggy that I can’t code. And reverting back to Net 5 seems like the wrong move. I just hope there is an update soon that makes this better.

  Great article. I just wish I was having the experience that you talk about and that I have seen in the VS 2022 release videos.

  • 

    Mika Dumont December 2, 2021 12:36 pm 0

    collapse this comment copy link to this comment

    Hi Shannon! Can you make sure your version is updated to 17.0.2? If the problem still persists after updating can you report the problem in Visual Studio so we can prioritize looking at the trace?

    • 

      Shannon Slaton January 24, 2022 6:35 am 0

      collapse this comment copy link to this comment

      It’s been almost two months and nothing has gotten better. VS 2022 slowly eats up all of my memory and CPU until my computer crawls. My fans are always at high. My laptop is burning up. VS 2022 has slowed my coding down by at least half. Sometimes it takes so long to get the debug to load that I forgot what I was doing. And I am on 17.0.5.

  • 

    Николай Михеев December 2, 2021 5:08 pm 0

    collapse this comment copy link to this comment

    A similar situation, but with a large project Blazor Server. Running from VS results in extremely poor performance.
    It takes minutes to wait for 1 character to be updated via Hot Reload … it’s impossible to work.

    But with dotnet watch, everything is fine. Only there is no debug, for it you need to run it already inside VS. But 99% of development is now with dotnet watch.

    Hopefully the performance will improve. otherwise I have 24 cores, and VS uses a maximum of 5% of the power. but dotnet watch already happens and 50%

• 

  グッド ジェシー December 2, 2021 12:39 pm 0

  collapse this comment copy link to this comment

  Just upgraded and I can notice a huge difference right off the bat. In @code blocks, it now actually recognizes the fields and properties as I type!
  But, as you mentioned there is a lot of work that needs to be done, just go look at the issues piling up everyday at https://github.com/dotnet/razor-tooling/issues.
  Before this update, the editing experience was so bad I literally was thinking using a plain text editor might be more productive (I’m only half-joking…). This blog post also gives me a little reassurance that Blazor/Razor is being given some priority also and with improved tooling maybe more people will jump on the bandwagon.

• 

  Giancarlo Sierra December 10, 2021 11:19 am 0

  collapse this comment copy link to this comment

  Hi and cheers on the new editor!

  I’ve found 2 apparent issues upon testing the new editor.
  1) The code folding for C# code is not behaving like a normal .cs file. For example, a method can usually be folded on the line it is defined – the new editor is folding the code 1 line below that. This seems to happen in any code structure. You can even see it in the pictures of this post, the code is folding on lines 37, 83, 93. The old editor (in VS 2019) would fold nicely on lines 36, 82, 92, respectively.

  2) The tab-tab (tab twice) feature for code snippets is not working well. When you type “if” for example, the editor suggests “if” as a keyword first, not a code snippet. It even includes a tooltip that says “Note: Tab twice to insert the ‘if’ snippet”, but it doesn’t work. You have to find the 2nd suggestion in the list and then hit tab to apply the snippet. This seems to happen with all default snippets.

  I’m running Windows 10.
  Microsoft Visual Studio Community 2022 (64-bit)
  Version 17.0.2

  I hope this helps!

• 

  Jan Seris January 9, 2022 10:27 am 0

  collapse this comment copy link to this comment

  I am sorry to say this, but the Razor editor is really bad experience to use compared to regular C# Visual Studio experience.
  I am watching dotnet and Visual Studio videos with you and your team regularly and all seems so promising but the result here is not nice.
  Feels almost like programming in IntelliJ IDEA with Java and far from VS 2019.
  I am running the newest VS 2022 version – 17.0.4.
  The list of the features missing or not working properly is incomplete.
  These important points are missing in the list:
  – Ctrl+Click doesn’t highlight method/class/property and allow Go To Definition
  – Undo/Redo is not available at all!
  – (part of the mentioned performance) – fixing compile errors (red underline) takes the syntax highlighter approximately 3 seconds to react (compared to a few hundred milliseconds in the C# editor)
  – F2 Rename for parameters of Razor components (Blazor components) doesn’t update their name in other files in the project!
  – old/non-existing Razor (Blazor) component parameters are not a compile-time error but crash the application during runtime upon first usage
  – syntax highlighter sometimes breaks completely – letters get random colors and VS 2022 restart is required (Note: still present in 17.1.0 Preview 2)
  – (part of the mentioned performance) – high CPU usage in the editor
  – pasting lines of code breaks their formatting
  – not only some code snippets like cw for Console.WriteLine() but also clever suggestions (VS 2022 feature) are missing
  – number of references and git info (last change, who) is missing above methods and properties

  It seems like this editor is just some fork of VS Code editor running in slow JS rather than a full Visual Studio native (WPF?) thing!