dotnet / razor

Compiler and tooling experience for Razor ASP.NET Core apps in Visual Studio, Visual Studio for Mac, and VS Code.
https://asp.net
MIT License
475 stars 187 forks source link

Refactoring is broken in razor editors - allow global namespace declaration #4425

Closed mayur-ekbote closed 2 years ago

mayur-ekbote commented 3 years ago

Both razor editors are broken beyond redemption (old and the new 'experimental). There are many issues. Autocomplete doesn't work, the editors refuse to recognize components, random crashes, and so on.

This makes refactoring a very time-consuming process. If you move around a component from folder A to B, its namespace automatically changes. Ideally, it should be a 1 click operation. Sadly, razor editors neither support "move to namespace" nor are they good at identifying the new namespace efficiently. It appears that there is no stable, functional update coming anytime soon. The editors have become progressively worse and impossible to work with.

To alleviate some of the pain, please allow the global namespace declaration. Like we have _Imports.razor allows the namespace to be declared at an RCL level. In project property or somewhere, one should be able to declare that all the components belong to only one namespace. This way, one can at least move components across folders without having to worry about the code breaking at runtime. (of course, component level @namespace can override the namespace declaration).

ryanbrandenburg commented 3 years ago

Could you please file an issue using VS feedback when you encounter the issues you're describing? Instructions are here: https://docs.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio?view=vs-2019#:~:text=In%20Visual%20Studio%2C%20select%20the,Send%20Feedback%20%3E%20Report%20a%20Problem.

Also could you go into more detail about your global namespace proposal? Would adjusting the namespace of components when they move folders solve your issues also?

mayur-ekbote commented 3 years ago

There are far too many issues with the razor editor. Many of these have been reported and are open. Reporting these again would be redundant. I am listing a few which coincide with my request.

dotnet/aspnetcore#33957 dotnet/aspnetcore#33928 dotnet/aspnetcore#33914 dotnet/aspnetcore#18987 Some general stability issues: dotnet/aspnetcore#33149 (most generic, yet very frequent. I have lost some of my edits at least on a dozen occasions) dotnet/aspnetcore#31616 (it is still there, even with VS 2022)

These issues are rare for small project samples but become more frequent as the solution size becomes bigger. I have a solution with 25 projects and out of which 6 are RCLs and one is the main blazor server application. All put together there are at least about 100 different razor components.

The issues related to file renaming are the most annoying because they effectively make any code refactoring near impossible.

  1. Suppose you have component A in project Proj under folder CompsA along with other files. The component namespace is Proj.CompsA
  2. You move A from CompsA to CompsB. The namespace is now Proj.CompsB. Changing the folder location effectively changes the namespace.
  3. Blazor can't find the component in the referring files.
  4. Yet no compile time error is generated the namespace exists (if there are other files in the folder CompsA).
  5. At runtime the component is rendered blank because blazor treats the component as plain html.
  6. To fix this, you need to manually go to every file which refer to component A because Visual studio is unable to flag this as error. In a regular C# project, "move to namespace" fixes all the references.

The solution should at least relieve us from the runtime this problem because it will always find the component in the global namespace (Proj).

mayur-ekbote commented 3 years ago

The razor file namespace <=> relative folder name also results in code break.

  1. Create a razor file (file.razor) and it's code behind (file.razor.cs). If they are created in CompA, both will be assigned namespace Proj.CompA. The namespace in the code behind file is assigned explicitly.
  2. Now move both files together to folder b. By convection, the razor file will have namespace Proj.CompB. Yet, the code behind file will still belong to Proj.CompA. This will result in compile time error
  3. There is no clean way to do this through VS. You can move the namespace of the CS file through the intellisense option, but it won't change the namespace of the razor component. And razor components don't have "move to namespace" option in refactoring.
  4. The only way to address this is explicitly assigning a namespace in every razor component. Hence the ask for specifying a namespace declaration at the project level. If by default all files are put inside, say Proj.Common, then intra project file movement won't matter.
  5. Matching package name with folder structure is ideal. You can instantly find the file you want. Given the current state of code refactoring in VS, it's a nightmare.
ghost commented 2 years ago

Thanks for contacting us.

We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

NTaylorMullen commented 2 years ago

@mayur-ekbote I love the enthusiasm and the passion you have for the area. Just to make things clear we definitely want to make the Razor editor better and love hearing feedback (even if it's negative).

I've seen your comments on other threads and it definitely sounds like you've been trying out VS2022 (awesome that you're on the bleeding edge!!). Do you happen to be on 17.0-Preview2 or Preview1?

So let me try and comment on a few of your concerns, and if you could validate if these are still concerns in VS2022 Preview2 that'd be great:

Autocomplete doesn't work

Could you elaborate?

This makes refactoring a very time-consuming process. If you move around a component from folder A to B, its namespace automatically changes. Ideally, it should be a 1 click operation. Sadly, razor editors neither support "move to namespace" nor are they good at identifying the new namespace efficiently.

Ya this is absolutely a pain point with the Razor editor and has been there since its beginning. Refactoring is quite the difficult task when ensuring everything works as expected. That being said, we haven't given a ton of thought towards refactoring namespaces although I can absolutely see how the lack of features can result in a less than desireable experience/many hours burnt. We'll keep this issue in mind for future releases once we've landed on making the 2022 Razor editor stable, performant and consistent.

Oh and have to say great idea on using _Imports.razor to enable refactoring at a certain level, clever ๐Ÿ˜„

It appears that there is no stable, functional update coming anytime soon. The editors have become progressively worse and impossible to work with.

We're looking to make VS2022 that release for you. I love the feedback you're giving so please keep giving things a shot in VS2022, Preview2+ ideally, so we can ensure it lands coherent for everyone!

In project property or somewhere, one should be able to declare that all the components belong to only one namespace. This way, one can at least move components across folders without having to worry about the code breaking at runtime.

If you set the RootNamespace in the csproj it'll let you change the "base"; however, the folders will still influence sub-namespaces. Your approach of utilizing _Imports.razor to further restrict this is a fine one. Ultimately I do think a tooling gesture would be the best way to make this a better experience though.

/cc @pranavkm in case you've gotten other requests for a csproj property to allow restricting the component namespaces further.

The issues related to file renaming are the most annoying because they effectively make any code refactoring near impossible.

Absolutely agree, something we need to make more seamless!

These issues are rare for small project samples but become more frequent as the solution size becomes bigger. I have a solution with 25 projects and out of which 6 are RCLs and one is the main blazor server application. All put together there are at least about 100 different razor components.

Definitely a decent app size. If you're up for it I'd love to continue working together to ensure the latest Razor editor in 2022 lands in tip-top shape; although we wont have time to do the folder/file renaming/moving refactorings sadly.

mayur-ekbote commented 2 years ago

@mayur-ekbote I love the enthusiasm and the passion you have for the area. Just to make things clear we definitely want to make the Razor editor better and love hearing feedback (even if it's negative).

๐Ÿ‘ I've seen your comments on other threads and it definitely sounds like you've been trying out VS2022 (awesome that you're on the bleeding edge!!). Do you happen to be on 17.0-Preview2 or Preview1?

Preview 2.1

Autocomplete doesn't work

Could you elaborate?

  1. Autocomplete cannot detect new components if the project is not built. Even if the fully qualified name is provided. Sometimes, it can't find the element at all even if the project is built and other elements are detected. This could also be because the compiler itself cannot find the component (the element is rendered as literal in dom is already raised in dotnet/aspnetcore#28312 . It's marked as done) See the video below:

https://user-images.githubusercontent.com/40038634/127831933-899a39c3-d098-47e6-bbc9-b33b3267bce0.mp4

  1. Autocomplete cannot access CSS variables, I have been told that CSS support is coming soon. It is important since blazor is largely a UI framework.
  2. Enabling experimental CSS and HTML support causes autocomplete to show all HTML tags and events even when one is only typing attributes of a razor component (class, aria-, id etc). I am not sure if a lot of people want to use HTML attributes on the razor component on a routine basis.
  3. IntelliSense (not autocomplete) comes up with weird suggestions if the project has build errors. Check the video below:

https://user-images.githubusercontent.com/40038634/127832889-800b6e25-0c09-4306-9abf-49576f4e810f.mp4

We're looking to make VS2022 that release for you. I love the feedback you're giving so please keep giving things a shot in VS2022, Preview2+ ideally, so we can ensure it lands coherent for everyone!

Yes. VS 2022 is much more stable than VS2019 for Blazor. That is the reason why I switched to 2022. 2019 was unusable with its very frequent crashes. It would be great if the team can address a few basic things on priority. Please do something about dotnet/aspnetcore-tooling#4357 It writes GBs per day. Also, check the example below:

GhostErrors

Definitely a decent app size. If you're up for it I'd love to continue working together to ensure the latest Razor editor in 2022 lands in tip-top shape; although we wont have time to do the folder/file renaming/moving refactorings sadly.

Absolutely. Let me know how I can be of help. I understood that VS team might be busy with the x64 migration. So I suggested a non-VS way of fixing the problem (_Imports.razor type solution would go through compiler I guess?? ). If you can address that through the tool, it would be great.

NTaylorMullen commented 2 years ago

@mayur-ekbote incredible write up!

  1. Autocomplete cannot detect new components if the project is not built. Even if the fully qualified name is provided. Sometimes, it can't find the element at all even if the project is built and other elements are detected. This could also be because the compiler itself cannot find the component (the element is rendered as literal in dom is already raised in Blazor rendering verbatim component instead of component html markupย #28312 . It's marked as done) See the video below:

This is super super odd. Given that runtime can't see it either it leads me to believe it's a Razor compiler issue but I can definitely help out here. Few questions:

  1. Does this happen consistently? Aka can you replicate it on demand or if it starts happening does it persist through VS restart?
  2. Would it be possible to share your project? I'd love to ensure that everything works 100% for you!

Autocomplete cannot access CSS variables, I have been told that CSS support is coming soon. It is important since blazor is largely a UI framework.

Would you mind providing a specific example so I can forward the bug to the appropriate team?

Enabling experimental CSS and HTML support causes autocomplete to show all HTML tags and events even when one is only typing attributes of a razor component (class, aria-, id etc). I am not sure if a lot of people want to use HTML attributes on the razor component on a routine basis.

Ya this is an interesting point. Currently this is something we're doing on purpose; however, I'd be curious to think of what others feel about this as well. @danroth27 do you have similar opinions / have you seen others feel the same?

IntelliSense (not autocomplete) comes up with weird suggestions if the project has build errors. Check the video below:

Ya this is real odd. Based on missing colorization in your project I think the whole system fell over to be frank. Assuming you can't repro this on-demand, next time it happens would you mind doing Report a Problem... in VS? It should capture enough logs for us to understand what went wrong.

image

Please do something about dotnet/aspnetcore-tooling#4357 It writes GBs per day

Yup definitely on our radar ๐Ÿ˜„. @dibarbet we can add this issue to our "please VS stop logging so much" effort.

Absolutely. Let me know how I can be of help. I understood that VS team might be busy with the x64 migration. So I suggested a non-VS way of fixing the problem (_Imports.razor type solution would go through compiler I guess?? ). If you can address that through the tool, it would be great.

You're doing great Your reports and interaction are exactly what enables us to deliver better experiences

dibarbet commented 2 years ago

Yup definitely on our radar ๐Ÿ˜„. @dibarbet we can add this issue to our "please VS stop logging so much" effort.

Added this to the internal tracking issue. I don't have a specific date, but there are people actively looking at this.

danroth27 commented 2 years ago

Enabling experimental CSS and HTML support causes autocomplete to show all HTML tags and events even when one is only typing attributes of a razor component (class, aria-, id etc). I am not sure if a lot of people want to use HTML attributes on the razor component on a routine basis.

Ya this is an interesting point. Currently this is something we're doing on purpose; however, I'd be curious to think of what others feel about this as well. @danroth27 do you have similar opinions / have you seen others feel the same?

Blazor components can capture arbitrary additional attributes specified on the tag and then render those attributes as needed: https://docs.microsoft.com/aspnet/core/blazor/components#attribute-splatting-and-arbitrary-parameters. So HTML attributes are valid if the component is authored to capture them. I don't believe its ever valid to offer HTML tag completions though when adding attributes.

mayur-ekbote commented 2 years ago
  1. Does this happen consistently? Aka can you replicate it on demand or if it starts happening does it persist through VS restart? It happens frequently, especially after many changes are made (components added/removed/renamed). But I have not been able to find a specific trigger. It used to happen in VS 2019 as well. Deleting .vs folder in the project would usually fix this. Now one has to delete the VSLogs folder.
  2. Would it be possible to share your project? I'd love to ensure that everything works 100% for you!

Can't. Proprietary code :(

Enabling experimental CSS and HTML support causes autocomplete to show all HTML tags and events even when one is only typing attributes of a razor component (class, aria-, id etc). I am not sure if a lot of people want to use HTML attributes on the razor component on a routine basis.

Here is more. This has suddenly started happening very frequently (still on 2022/2.1, so it is not as if some update introduced this). Check out the CPU usage surge the moment I start typing. Note that I am continuously typing in the video.

https://user-images.githubusercontent.com/40038634/129056976-5d7bce86-2bb4-4184-8af4-3a915a7b1e5b.mp4

Ya this is real odd. Based on missing colorization in your project I think the whole system fell over to be frank. Assuming you can't repro this on-demand, next time it happens would you mind doing Report a Problem... in VS? It should capture enough logs for us to understand what went wrong. My guess is that this is an overall stability/background operations issue. Sometimes, if I wait for a very long time some issues disappear. (My system config: i5 8400/ 2.8 GHz/ 6 core/ 24 GB RAM/ 970 Evo NVMe). Sometimes, they don't. For example, the reason I switched to VS 2022 is that 2019 had become unusable. It literally crashes every 15 minutes. Check the video. While this is much less frequent in 2022, it is still there and happens without warning.

https://user-images.githubusercontent.com/40038634/129057042-bab931d9-fcee-403d-8ecc-07d16529efbd.mp4

The VS feedback thing is nice. However, I feel the release cycles feel too long for these absolute showstoppers in blazor. (For example, now I can't even type div without fixing it in two places! Together with the high CPU issue above, it is nearly impossible to do anything.)

https://user-images.githubusercontent.com/40038634/129057106-5bc3c659-931f-44cb-afde-1eb6b39a3772.mp4

My experience with VS feedback has been mixed. For example, I followed the "report an issue" process. While the issue is being considered right now, I found out that it was raised first in Aug 2017! If you search the issue, you will see that it was raised at least half a dozen times and it was either closed for want of more info, was considered "low priority" or marked as "fixed"

Issue: ViewManager.ActiveView must be a View contained within the ViewManager.WindowProfile https://developercommunity.visualstudio.com/t/The-ViewManagerActiveView-must-be-a-Vie/1492891

NTaylorMullen commented 2 years ago

Can't. Proprietary code :(

Totally understand! Lets see what we can do to make things great without that.

Here is more. This has suddenly started happening very frequently (still on 2022/2.1, so it is not as if some update introduced this). Check out the CPU usage surge the moment I start typing. Note that I am continuously typing in the video. now I can't even type div without fixing it in two places! Together with the high CPU issue above, it is nearly impossible to do anything.)

Ahhh, I'm actually pretty sure all of these (including the div auto-complete) were fixed in 17.0-P3 which is now released. Would you mind trying that build out and reporting back?

My experience with VS feedback has been mixed. For example, I followed the "report an issue" process. While the issue is being considered right now, I found out that it was raised first in Aug 2017! If you search the issue, you will see that it was raised at least half a dozen times and it was either closed for want of more info, was considered "low priority" or marked as "fixed"

I can definitely understand how it can be inconsistent response times. Depending on the team involved they can be more or less underwater with issues ๐Ÿ˜„. That being said I'll be on the other end of "Report an issue" for Razor editor related problems so hopefully we can dig through this together

mayur-ekbote commented 2 years ago

Ahhh, I'm actually pretty sure all of these (including the div auto-complete) were fixed in 17.0-P3 which is now released. Would you mind trying that build out and reporting back? Been wanting to do that since morning. It finally appeared in my feed.

I can definitely understand how it can be inconsistent response times. Depending on the team involved they can be more or less underwater with issues ๐Ÿ˜„. That being said I'll be on the other end of "Report an issue" for Razor editor related problems so hopefully we can dig through this together

:)

Btw, for all this complaining, I have nothing but positive things to say about the new AI code completion. It is mind-blowing! It works so well. Please pass on my compliments to whoever is working on that.

mayur-ekbote commented 2 years ago

I have been using VS2022 P3.1 for about three weeks now. It is stable and most of the other issues seem to have gone now. If I take up another refactoring exercise and see anything creeping back I will update.

mayur-ekbote commented 2 years ago

Post .net 6 (preview 7) migration the IDE has become very unstable (I was on .net 5). Random crashes and high CPU usage are extremely frequent. PFA new type of issue.

https://user-images.githubusercontent.com/40038634/132571105-a239a31a-aec1-4bbe-8156-566d910a550e.mp4

NTaylorMullen commented 2 years ago

@mayur-ekbote there was a huge issue with SourceGenerators making the IDE unstable. Would you mind trying your scenarios with VS2022 - Preview4 and reporting back?

mayur-ekbote commented 2 years ago

So I have been using 4.1 for quite some time. The editing seems fine so far. But the debugging experience has worsened.

  1. Sometimes "Edit and Continue" prompt goes on for quite some time. Especially if large number of changes have been made before running. Sometimes it crashes the visual studio.

  2. Sometimes, the debug points don't hit at all. It just happens intermittently: https://user-images.githubusercontent.com/40038634/136452500-87101a87-8ef6-4869-9e66-fb99ea06e1a8.mp4

  3. I did a clean install of the OS + VS and then pulled my project from remote. It compiles and runs fine. But now I can't add a new razor file!

https://user-images.githubusercontent.com/40038634/136452566-830cb5eb-2521-45a8-bcc5-d80deb2a0410.mp4

Package

  1. "Formatting selection" type crashes are still there, albeit less frequent.

Btw, is hot reload supported yet? I could never use it successfully on my Blazor server app.

NTaylorMullen commented 2 years ago
  1. Sometimes "Edit and Continue" prompt goes on for quite some time. Especially if large number of changes have been made before running. Sometimes it crashes the visual studio.

@danroth27 this is known and fixed in P5 right?

Sometimes, the debug points don't hit at all. It just happens intermittently: https://user-images.githubusercontent.com/40038634/136452500-87101a87-8ef6-4869-9e66-fb99ea06e1a8.mp4

Ya that seems super concerning, really appreciate the video! @danroth27 known?

I did a clean install of the OS + VS and then pulled my project from remote. It compiles and runs fine. But now I can't add a new razor file!

@vijayrkn this seems really bad, does this happen to be known / fixed in p5?

NTaylorMullen commented 2 years ago

Oh and @mayur-ekbote super appreciate the detailed report, thank you thank you thank you!

danroth27 commented 2 years ago

There are a number of issues with hot reload in VS2022 Preview 4.1 that will get addressed in the next preview update, but please submit VS feedback issues from any hot reload problems you hit so that we can make sure all the issues have been addressed.

mayur-ekbote commented 2 years ago

@danroth27 I have never been able to get hot reload to work. Every time I click on the hot reload button I get a message that there was a build error, the changes could not be applied, and I need to stop debugging and rebuild the project.

I have a fundamental question: Is hot reload supposed to work if I make changes to the transitive dependencies of the startup project? Does it propagate changes all the way through the dependency path? I couldn't find any VS 2022 documentation on that.

danroth27 commented 2 years ago

@mayur-ekbote What sort of project are you working with? Hot reload should work reasonably well with MVC, Razor Pages, and Blazor. Hot reload only works with Blazor WebAssembly when running without the debugging. Transitive dependencies should be fine.

mayur-ekbote commented 2 years ago

@danroth27 I am using Blazor server. I finally managed it to get to work. Initially for minor changes it worked fine. But later on it took very long time to apply changes (much much longer than the build time). Trying to stop it does not work. Anyway, I have raised the issue on the feedback portal. I am hoping that things will improve overall as we move closer to the final release.

Thanks!

mayur-ekbote commented 2 years ago

Anti-ghost errors are back. Apparently the build fails because of some errors (actually there should be no errors.) . But there is no way to know what those errors are. Restarting VS etc doesn't work. Update: The actual build log shows the error but it is not reported on the UI

https://user-images.githubusercontent.com/40038634/136654630-fd528ca5-8d78-4110-8343-d16e248571c1.mp4

NTaylorMullen commented 2 years ago

@mayur-ekbote it looks like your issue is non-editor related. Would you mind filing a different issue encompasing your build failure example in the dotnet/aspnetcore repo?

mayur-ekbote commented 2 years ago

I am not sure about that. Because the console output shows the exact error. Only the error window is not update.

NTaylorMullen commented 2 years ago

@mayur-ekbote Ah errors not showing up in the error list is tracked here