icsharpcode
Future of NRefactory
With the recent APL release of Roslyn, I can't help but think about what this means for NRefactory. My primary interest is in the parser and resolver since those are what I use.
I'm not saying that NRefactory, as it currently is, does not have its place, but I can also see the possibility of NRefactory turning into a refactoring library backed by Roslyn.
Now that there seem to be a new version of C# with new language features, I need to know whether I can count on the parser and resolver in NRefactory to continue evolving to include those features, or if I need to start the work of migrating my project to a Roslyn-based solution.
Sorry for asking this "elephant in the room"-kind of question, but I need to know what the plans are.
ATM I think thet NRefactory will turn into a library based on Roslyn. As you said it does not have it's place right now.
Roslyn will define the C# language and it's very similiar to what NRefactory does - I haven't fully explored roslyn yet. But the best thing NRefactory can achieve in the future is having roslyn like stability. We still have some issues on parser & resolver level and roslyn basically solves all issues for us. I don't know if roslyn is stable enough atm but long term I do not see thet our parser and resolver will get the new features.
The parser will get c#6 I think but I would recommend migrating to a roslyn base. All other options do not make sense for me. What do you think ?
If Roslyn is indeed ready to be used (as in, as stable or more stable than NRefactory) as a parser, formatter, etc. then I'm all for using it. I think NRefactory does not have to migrate to Roslyn all at once. If certain components from Roslyn are not ready, NR could perhaps have a compatibility layer that converts Roslyn AST to NRefactory AST and use the current NRefactory code for those parts.
In particular, I propose using this compatibility layer for the code actions/issues that already exist, but write new actions/issues with the new Roslyn AST directly.
I think you are right, using Roslyn is probably the better option. I don't know about its current state, but I think it is likely to be in a stable state rather soon.
Yes, NRefactory will most likely be based on Roslyn. Roslyn's AST is more suitable for use in IDEs (immutable, supports incremental parsing, better error recovery). I haven't looked at semantic analysis (resolver) in Roslyn yet, but we'll likely want to use that instead of reimplementing the C# spec.
However, ILSpy is a different beast... it has a completely different use case for the NRefactory AST: it uses it only for code generation (doesn't need a parser), and makes heavy use of pattern matching and in-place AST mutations. So we'll probably want to keep the NRefactory AST (or some simplified version of it) around for this purpose.
After investigating Roslyn a little, it seems to me that it doesn't have the equivalent of NRefactory's ResolveResult. I don't know if I'm just missing something obvious, or if it is expected to arrive, but it is a crucial component for me (and possibly for others).
Actually, these types (of course; because the compiler needs them) exist, but they are all internal (Microsoft.CodeAnalysis.CSharp.BoundExpression and friends).
I noticed that some Roslyn-related commits were made recently, so I assume you've decided which strategy to use for this. Any specifics?
I try to port the high level IDE features. Atm code completion and I started the code issues.
The code issues and actions are a problem because they didn't open the code action API (but the issues for some reason). There are some other IDE APIs that can be ported. Semantic highlighting & indentation engine for example. I'll port it subsystem per subsystem and replace it in Monodevelop & see in which problem I'm running.
What do you think will happen to the resolver? As per the Roslyn discussion mentioned above (https://roslyn.codeplex.com/discussions/541303), Roslyn's resolver is internal, and they only publish a subset of its result (and IMO in a quite quirky way)
What is the recommended way to setup the NRefactory roslyn branch?
Using Visual Studio + NuGet does not work. There are tons of missing classes (notably in Microsoft.CodeAnalysis.CSharp.Extensions, Microsoft.CodeAnalysis.CodeFixes and Microsoft.CodeAnalysis.CodeActions) and the error messages indicate that NRefactory expects a monodevelop/main/external/roslyn/bootstrap folder to exist.
The source code for monodevelop doesn't seem to have this folder. Is this some new branch? If so, did you ever push it?
Atm the roslyn version is a mess. I can't set up roslyn properly on mono. I need to build it with a makefile. I would recommend setting up a local branch and just trying to correct the dll references.
But roslyn changes at a rapid rate so getting it to build is just coincidence.
I think using Rolyn as a backend is the right way to go too.
I'm currently working on adding some code completion features to CShell. So far I have been using NRefactory for code completion, and last time I looked Roslyn's completion was far from usable. I really like the NRefactory code completion, plus it plays really well with AvalonEdit. So what is the status with Roslyn code completion and what NRefactory code completion APIs are you going to keep?
Let me know if you need help with anything, I really want to see this refactoring succeed.
See:
https://github.com/icsharpcode/NRefactory/tree/roslyn/ICSharpCode.NRefactory.CSharp/Features/Completion
The roslyn branch contains all.
Most unit tests are working in the roslyn based completion - but some aren't. The parameter completion (I call it now hinting) already works better than the NRefactory based one because I was able to fix some parser related bugs.
The API is more or less the same. But I invested some time in proper API design this time - it should be easier to use and more stable for future extensions.
That's great news! So would you advise to switch already to using the roslyn branch, or should I wait a little longer?
Yes use it ... it's 'the future' :)
you'll need https://github.com/mono/roslyn/tree/monodevelop to build it ... I needed to give nrefactory the internals of roslyn to access important parts.
Nice, will do that. That's what my explorations lead me to too: that some of the internals are needed to do some of the more powerful stuff. Nice that NRefactory is taking care of this and makes it available as a nice API!
Hi. So I was thinking of using NRefactory to enable some C# refactoring capabilities in Vim. I know there's OmniSharp out there but my experience with it wasn't so smooth. So I'm willing to put the time and effort and create my tool. But reading the comments above made me a bit skeptical of what should I do, what direction should I go forward with. Also, there's a lot of opened issues with no replies. Will support for NRefactory continue? - Can I just start learning NRefactory and don't worry about anything else?
NRefactory 5 support will probably continue for some time, maybe it'll even get support for the C# 6 features (though we're unsure about that). The 'roslyn' branch of NRefactory is really a different NRefactory -- lots of classes have been removed because roslyn already provides equivalent APIs, and just the parts that have no direct correspondence in Roslyn remain. The 'roslyn' branch will likely be supported for longer, as it'll be used in future MonoDevelop versions.
Hi. I'm wanted to use NRefactory AST built from roslyn ones, but I can't find roslyn branch anywhere. Is it in different repo?
There was never an implementation to built the NRefactory AST from the roslyn one
@mkrueger ;(, I thought that NRefactory based on Roslyn is implemented, as you wrote that it is the future and we should use it.
The NRefactory version in this repository is not based on Roslyn, and likely will never support C# 6.
The refactorings in NRefactory were ported to Roslyn, but moved into a separate repository: https://github.com/icsharpcode/RefactoringEssentials With the refactorings gone, the NRefactory roslyn branch no longer contained anything of use and was deleted.
I ment with roslyn is the future that roslyn replaces NRefactory mostly. It doesn't make sense to maintain a library that does the same than roslyn does.