Code browser/All members - support for razor files
Jarek300 opened this issue · 5 comments
The command "File browser' supports razor files. Unfortunatelly, The command 'Code browser/All members' shows error message: "This non-code file type is not supported".
Razor files in Blazor projects contain '@code' section where members can be declared.
Thanks, I'll investigate. I suspect that file type is unlikely to expose the code model to VS extensibility APIs. If that turns out to be the case, which I suspect it will, then it won't be supported unfortunately.
Long term plan for DPack Rx is to move away from VS extensibility APIs that handle code model and transition to Roslyn instead. About the only thing that stops me is lack of C++ Roslyn support.
Investigated it and as I suspected it extensibility accessible code model isn't made available. So technically it'd be doable if I were to convert to Roslyn parser for code model information retrieval. As I mentioned in another reply, it'd ultimately leave C++ support out as there is no Roslyn support for C++ available yet. So that would mean 2 separates code model parsers (Roslyn for C#/VB and something else for C++), which I'm just not prepared to tackle at this time. Now, if someone wanted to take on plugin in C++ side of things then I could work on abstracting the code model retrieval to make it extendable. That's something to consider for future releases.
I'm not sure what are your plans for Roslyn parser. Are you going to use it and add support for records, razor files and all future features? Or stay with current parser and support C++ files? Or create DPack 2022 and DPack 2022 C++ Edition?
I definitely have no plans for maintaining 2 code bases. Ideally, I'd convert to Roslyn but unfortunately, I'd have to drop C++ support, or at least make code model pluggable enough so that C++ support code be done via different parser. I'd need someone else to investigate parser choices and likely write a service for that. It'd take quite a bit of refactoring to even get to that point. So until I get volunteers to help out and enough interest to undertake this effort, the status quo will be maintained.
FYI, I've been exploring Roslyn integration for C#/VB. Made a decision to move forward as I ran into scenario where one particular feature was only accessible via Roslyn now. Thought I'd let you know.