Answering Your Questions: AMA with the .NET Team on Reddit
Last week, we held our first Ask Me Anything (AMA) session on Reddit. We’d like to thank everyone who participated, and we hope you found it useful!
What did you think of it? Would you like us to do another AMA session in the future? Please let us know in the comments!
If you missed the session, here’s an overview of the most popular and interesting questions. For your convenience, we broke them down into three categories: ReSharper, Rider, and our .NET team.
- Questions about ReSharper
- How about releasing ReSharper for Visual Studio for Mac?
- Any plans to ever support VS Code in ReSharper? Or bring VS Code extensions into Rider?
- Does ReSharper use Roslyn? Do you plan to move to Roslyn?
- What about performance of Visual Studio with ReSharper?
- Have you considered making an introduction to ReSharper and other educational deep-dive videos?
- Are there any plans to incorporate ML into ReSharper at some point?
- Questions about Rider
- Will there be a community edition of Rider?
- Are there plans to rework Rider’s UI/UX?
- What’s your long term (2-3 years) vision for Rider?
- When will we see the Windows version of Rider using the .NET Core backend?
- When can we expect Rider to run on Apple Silicon M1 chips?
- Thoughts on native WSL2 support for Rider?
- When will the XAML support be added to Rider for .NET Core?
- Any plans for when C++ support will be landing in Rider?
- Any ETA on production-ready Rider for Unreal Engine?
- What is the plan to bring dotMemory and dotTrace to Linux and macOS?
- Will dotPeek become cross-platform?
- Questions about JetBrains .NET Team
- How big is the .NET team?
- What process are you using (SCRUM, Kanban, something else)?
- What languages does the codebase that the .NET team directly maintains consist of?
- Are you sharing functionality with other products? If so, how much and how does the work of other teams affects you?
- How do you decide what features or bugs to work on next? To what extent can a single developer decide for themselves what to look into?
Questions about ReSharper
How about releasing ReSharper for Visual Studio for Mac?
There are no plans to release ReSharper to Visual Studio for Mac. We believe in Rider as our .NET IDE that provides the same experience cross-platform and includes all the polished features from ReSharper, IntelliJ IDEA (support for VCS, Docker, run configurations, local history, and much more), DataGrip (DB management), and WebStorm (frontend). For getting an idea how that looks like, we’re recommending the Rider section in our .NET Guide.
Any plans to ever support VS Code in ReSharper? Or bring VS Code extensions into Rider?
No, we don’t have such plans. VS Code uses the Language Server Protocol (LSP), which provides a universal way to support pretty much any language. The downside is it also limits the features that can be implemented. Some background on this topic can be found in our article entitled “Building a .NET IDE with JetBrains Rider”, in the "The Need for a Custom Protocol" section.
As for Rider, this would require us to build and maintain an interoperability layer on top of the model our IDEs use. We instead concentrate on building the IDE itself.
Does ReSharper use Roslyn? Do you plan to move to Roslyn?
We actually had an interview about using Roslyn with two of our developers back in 2014. In short, there are 2 reasons for not doing this:
- It would be a tremendous effort;
- It is architecturally incompatible with our features.
It’s also important to note that Roslyn only supports 2 languages (C# and VB.NET), whereas ReSharper and Rider are multilingual.
What about performance of Visual Studio with ReSharper?
One of the main causes for performance issues is Visual Studio (VS) being a 32-bit process that even on beefy machines can only really use 2-3 GB of memory. This process has to hold VS, Roslyn, ReSharper, and many other extensions that ship out of the box, and are all competing for memory. If you’re interested, attach a profiler and have a look at the memory traffic and garbage collection going on. Nobody is to blame here, and it’s also not easy for Microsoft to move away from 32 bit, which is unfortunate, but that’s the way it is.
Microsoft is moving some parts of .NET support out of the VS process, and we’re working on a similar solution as well, "ReSharper out of process", where the plugin that lives in VS would be a layer to communicate with another process that is the real ReSharper. This is a big refactoring, and on top of that, it is a refactoring that is happening while new .NET versions and new C# versions are being released. It’s like changing a car’s wheels while driving on a highway. We can’t yet promise a release date, but we’re hard at work to make this happen.
In each new version of ReSharper, we fix a number of performance issues as they’re our priority. We have a tracking issue that collects a lot of background posts about performance and identifies what we’re working on. Make sure to look through the linked blog posts in the issue if you want more background on this.
If you look for ideas on how to speed up your development experience, we have a workaround that works well for many solutions and helps free up memory (though your mileage may vary). Lastly, have a look at the Performance Guide for Visual Studio as well as our article about Speeding up ReSharper and Visual Studio. If you have a specific performance issue that you can reproduce, we’d appreciate it if you could collect a performance snapshot and send it over to us.
Have you considered making an introduction to ReSharper and other educational deep-dive videos?
We frequently give public talks about our products at conferences and user groups. We always try to address the full experience scale, ranging from beginners, who’ve never heard about ReSharper or Rider, to intermediate and advanced users. Our goal is to teach everyone something new! Some of these talks are publicly available on well-known video platforms. We also maintain a .NET Guide on our website and tweet tips via @resharper and @JetBrainsRider. If you’re taking part in a user group, feel free to reach out, and we can organize a (virtual) visit!
Are there any plans to incorporate ML into ReSharper at some point?
We don’t have plans to introduce any ML capabilities in ReSharper, but we are working on it in Rider (since the IntelliJ platform already supports ML completion for a variety of languages). Hopefully, something will be released in 2021.1, stay tuned!
Questions about Rider
Will there be a community edition of Rider?
Currently we don’t have plans to release a community version of Rider in the near future. At the same time, you might want to check out our free license programs for students, teachers, OSS maintainers, user groups, and many others. Also, Rider EAP (Early Access Program) should be open somewhere in February. Additionally, Nightly builds are free of charge.
Are there plans to rework Rider’s UI/UX?
We’ve actually made a lot of updates to the UI since Rider was released in August 2017. We’ve updated the default themes, removing a lot of the enterprise grey, flattening the UI, and replacing the entire icon set. In fact, the UI now supports custom themes, and many are available as plugins (learn more). Rider also has several editor color schemes, and they are available as a plugin for other IDEs, as well.
We’ve introduced a custom drawn title bar for Windows, reducing wasted vertical space. The 2020.3 release brought in a new, simpler Welcome dialog, which is discussed in a post on the IntelliJ blog, and we recently reworked the version control tool windows to make better use of vertical and horizontal layouts, including putting the diff windows as an editor tab. We even created our own font Mono for the editor.
By default, there is only one toolbar shown for a new user, along with the navigation bar. The only tool window shown by default is the Solution Explorer, and there are no more tool windows than there are in any of our other IDEs. All tool windows can be shown, hidden, and resized from the keyboard, and they can be moved around to different locations in the IDE. They can be docked, pinned, or floating, providing some support for multi-monitor setups, and we are actively working on improving this experience, including drag and drop docking support. We’ve recently introduced better support for dragging and dropping editor tabs to make tab groups.
The Rider team has devoted a lot of attention to context menus, and we’re trying to maintain a balance between size and functionality, especially in the editor and the Solution Explorer.
Long story short, we’re constantly looking at the UI/UX of Rider and the other IntelliJ products, and we want the IDE to both look good and also be good to use. With Rider, for example, we’ve tried to make the Alt+Enter menu the main entry point to the vast majority of Rider’s features. You can always use Alt+Enter to get to the navigation, refactoring, and generation menus, for example, or you can just start typing to search for actions.
What’s your long term (2-3 years) vision for Rider?
While it’s hard to make 3-year predictions for such a rapidly growing and changing market, we’ve identified a few directions in which we want the product to grow: general cross-platform .NET development; web development with ASP.NET and ASP.NET Core; cloud .NET development; mobile development, especially Xamarin; and of course, game development (in the broadest sense). For each of these directions, we are carefully investigating the market, the most commonly used technologies, and typical developer workflows and approaches, and we’re doing our best to support the most essential and widely used of them in the product. This helps us build our roadmap, which we are happy to share with our blog readers here.
When will we see the Windows version of Rider using the .NET Core backend?
We hope to release it this year. We already have a working prototype, but there are some technical problems that have not yet been resolved (e.g., we should support Windows-only technologies like WinForms and WPF, replace NGen with CrossGen, etc.) The optimistic estimate is Rider 2021.2, but it could still be postponed to 2021.3.
When can we expect Rider to run on Apple Silicon M1 chips?
Last year, we migrated from Mono to .NET Core on macOS and Linux, the main reasons for that being performance and stability (see our blog post on the migration). To run Rider in fully native mode on M1, we’ll have to wait until .NET Core is able to run on these CPUs (assuming the JVM part is ready for them).
Currently we’re thinking about preparing some sort of intermediate build, where the frontend process will run on M1 natively and the backend process will run on Rosetta 2 (the hypothesis being that performance of the backend process is not as critical for the perceived IDE performance as the frontend). Whether we’ll publicly release any results of this experiment fully depends on how stable it is, and how soon Rosetta 2 will be able to run .NET Core programs without significant problems (it seems that Apple is working on it; see details).
Feel free to subscribe to the tracking issue, where we’ll publish any news.
Thoughts on native WSL2 support for Rider?
Support for WSL 2 is pretty complicated. Essentially, it requires a full local development experience, but while storing the code and running some of the processes on a remote machine with its own file system and set of software (mind Git and .NET SDK, including MSBuild which we usually host on our side), as well as things like Docker.
We’re slowly moving towards it, but we don’t expect it to land in the next 2021.1 release.
When will the XAML support be added to Rider for .NET Core?
We’re currently rebuilding our XAML previewer platform to be ready for future changes. In 2021.1, we expect a significantly better XAML previewer for .NET Framework projects, and later we’re planning to release a previewer for .NET Core, too. It is a long process because of the technological challenges (it’s not easy to integrate a whole window from an external process directly into our UI), but we’re working on it right now.
Any plans for when C++ support will be landing in Rider?
We now have Rider for Unreal Engine which brings C++ and UE-specific support to Rider. The main targeting is game development, as our main C++ IDE is still and will be CLion. However, if you have an MSBuild project and want some tool to substitute VS for it, Rider will work for you and you can use it that way.
Any ETA on production-ready Rider for Unreal Engine?
We are now working hard to bring Rider for UE to macOS (most of it has been ported already) and Linux (work on this has just started). We are also trying to get access to the console’s SDKs and devkits from the vendors. This process takes a lot of time and effort, and unfortunately, it is a showstopper for console support in Rider. We need the latter to investigate the opportunities for Rider to integrate with major consoles. Another major point to be resolved before the official release is the quality of the debugger (which we implement on top of LLDB on our own). Once we are satisfied with all of this, we’ll be ready for the release. We do hope it will happen in 2021, but we can’t provide you with an estimate at this point.
What is the plan to bring dotMemory and dotTrace to Linux and macOS?
The profilers should work, either in Rider or command-line. Inspecting snapshots is another story. Cross-platform UI for that is under development.
Will dotPeek become cross-platform?
It already is, in the form of Rider. Of course, you need a project/solution open, but most of the dotPeek functionality is there.
Questions about JetBrains .NET Team
How big is the .NET team?
We currently have 131 members in our .NET department, which includes the teams from ReSharper, Rider, dotMemory, dotPeek, dotTrace, and dotCover, as well as a variety of positions in development, QA, marketing, and advocacy. Since our tools are heavily integrated, there are no clear boundaries. Communication between different teams happens quite regularly. For instance, our Rider developers work closely with the IntelliJ team, and members of our dotTools help with the integration in our IDEs.
What process are you using (SCRUM, Kanban, something else)?
Each team is responsible for its own product, including its development process. Teams may use whatever way they think works. That said, in the .NET department we usually have a planning meeting once per release. Important milestones in the development of specific tasks are often openly discussed in a dedicated meeting with the whole team where everyone can bring up their thoughts.
What languages does the codebase that the .NET team directly maintains consist of?
The majority of ReSharper and Rider’s backend code is written in C#. I’d said it is about 85% of the codebase. For the sake of dogfooding some of the code that deals with VB.NET support is written in VB.NET and C++ support is written in managed C++. Likewise the F# plugin is written in F#.
Rider’s frontend (the part that is integrated into IntelliJ Idea) is written in Kotlin. There are some pieces of native code in C++ around LevelDB (the database we use for caches) and in profilers.
The code that does process instrumentation for the profilers and dotCover is pure C++, but the viewers and data processing are written in C# and WPF. We are rewriting some of the views in Avalonia in order to have a cross-platform profiler’s UI in the future.
Are you sharing functionality with other products? If so, how much and how does work of other teams affects you?
We share a huge amount of functionality across the different IDEs based on the IntelliJ Platform, such as IntelliJ IDEA, Rider, WebStorm, GoLand, DataGrip, and so on. They’re all built on the open-source IntelliJ Platform, which provides a core framework for building an IDE – the editor, support for project systems, language parsing and indexing, inspections, Alt+Enter refactorings, debugging, and loads more.
Most features are built as plugins, and the teams responsible for specific IDEs are free to bundle the plugins they want. This is a great solution for us because we can share functionality, we can have teams that focus on specific features, or even on an entire IDE, but the feature set can be shared across all IntelliJ-based IDEs. A good example here is DataGrip. It’s a great standalone product, but it is also built as a plugin, which means Rider (and many other IDEs) can bundle it and provide first-class, integrated database tooling.
Also, we have a great IDE for web development in WebStorm, and Rider can have great web functionality, effectively for free, allowing the Rider team to focus on core Rider features, like .NET integration and so on. Speaking of Android Studio, Rider can pull in the Android functionality from the official Android IDE to support Xamarin development.
Working with other teams also tends to work just fine. JetBrains has a very flat structure, with very little bureaucracy. This means it’s very easy to talk to other teams and give feedback or request features. Things aren’t always perfect – we still get breaking changes and experience other hiccups, but we try our best to minimize these.
Rider has more difficulties than the other IDEs due to its architecture. Most IDEs based on the IntelliJ Platform build support in the same way. The project model, language parsers, inspections, the debugger, and more are all written in Java and Kotlin and run in a process in the JVM-based IntelliJ app. Rider uses the IntelliJ Platform as the frontend but uses ReSharper as the .NET language engine. So Rider has a lot of facades on the IntelliJ side that talk to ReSharper running as a headless service (you can read more about this architecture here). But this means that there is less information available on the IntelliJ side for plugins to be able to do something interesting. For example, the Rainbow Brackets plugin uses a file’s syntax tree to find matching braces and highlight them in a different color per scope. For a long time, there wasn’t a syntax tree on the IntelliJ side, so it wasn’t possible to implement this for C#. Recent versions of Rider have included a simple syntax tree, so it’s now possible to implement, but there are still some features that aren’t available because the syntax tree isn’t fully featured. It works both ways – some of Rider’s features are provided by ReSharper, and so they aren’t available in other IDEs. And of course, even similar features available in both IntelliJ and ReSharper can be very different architecturally, which means it’s very hard to bring features across. An example of this case is Structural Search and Replace, which works differently in ReSharper than it does in the IntelliJ Platform.
How do you decide what features or bugs to work on next? To what extent can a single developer decide for themselves what to look into?
This might vary a bit from team to team, but in general, developers have a lot of freedom over the tasks they want to work on. Apart from serious regressions, every developer can choose for themselves what they want to implement next and start working on fixing a bug or implementing a feature without any formal approval process. However, large features that might have performance implications are presented to the team and discussed before they make it into the product. There are also language support tasks that must be finished before the next version of the language is released, regardless of whether there’s a developer who wants to take ownership of a language feature. Such tasks are usually discussed when the feature set for the next language version is finalized and assigned to developers based on their workload and expertise in the particular area affected by the language feature.
We hope you enjoyed our AMA session! Please remember our blog and social media channels are always open to questions, so don’t hesitate to get in touch with us. If you’re experiencing issues, contact us on Twitter, file a support ticket, and use our issue tracker. We’re here to help!
Subscribe to a monthly digest curated from the .NET Tools blog:
