回答你的问题:Reddit上的。net团队的AMA
上周，我们举行了第一次Reddit上的“随便问我”(AMA)会议．我们要感谢每一个参与的人，我们希望你觉得它有用!
你觉得怎么样?你想让我们在未来再举办一次AMA会议吗?请在评论中告诉我们!
如果您错过了会议，这是最受欢迎和有趣的问题的概述。为方便起见，我们将其分为三类：Resharper，Rider和我们的.NET团队。
- 关于重新磨术的问题
- 关于骑手的问题
- 关于JetBrains .NET团队的问题
关于重新磨术的问题
如何发布resharper for Mac的Visual Studio？
没有计划发布ReSharper为Mac Visual Studio。我们相信骑士作为。net IDE提供同样的经历跨平台和包括所有抛光特性从ReSharper, IntelliJ IDEA(对风险投资的支持,码头工人,运行配置,当地历史,等等),DataGrip (DB管理),和WebStorm(前端)。为了了解它是什么样子的，我们推荐骑手部分在我们的。net指南中。
有没有计划在ReSharper中支持VS Code ?或者将VS Code扩展引入Rider?
不，我们没有这样的计划。VS代码使用语言服务器协议（LSP），该协议提供了一种支持几乎所有语言的通用方式。缺点是它还限制了可以实现的功能。本主题的一些背景可以在我们的文章中找到“用JetBrains Rider构建一个。net IDE，在“自定义协议的需求”一节中。
对于Rider来说，这需要我们在我们的ide使用的模型上构建并维护一个互操作性层。相反，我们集中精力构建IDE本身。
ReSharper使用Roslyn吗?你打算搬去罗斯林吗?
我们有一个采访使用Roslyn和我们的两个开发者在2014年。简而言之，有两个不这样做的原因:
- 这将是一个巨大的努力;
- 它在架构上与我们的特性不兼容。
同样重要的是，Roslyn只支持两种语言(c#和VB.NET)，而ReSharper和Rider是多语言。
Visual Studio与ReSharper的性能如何?
造成性能问题的一个主要原因是Visual Studio (VS)是一个32位进程，即使在健壮的机器上也只能使用2-3 GB内存。这个过程需要VS, Roslyn, ReSharper，以及许多其他的扩展，它们都在争夺内存。如果您感兴趣，可以附加一个分析器，并查看正在进行的内存流量和垃圾收集。在这里没有人应该受到责备，微软也不容易离开32位，这是不幸的，但这就是它的方式。
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.
在ReSharper的每个新版本中，我们都修复了一些性能问题，因为它们是我们的优先级。我们有一个跟踪问题它收集了大量关于性能的背景帖子，并确定了我们正在进行的工作。如果你想了解更多的背景信息，请务必浏览相关的博客链接。
如果你想知道如何加快你的开发经验，我们有一个对许多解决方案都有效的解决方案，并有助于释放内存(尽管你可能会有所不同)。最后，看看Visual Studio绩效指南以及我们的文章加速重新刹车和视觉工作室．如果您有可以重现的特定性能问题，我们将非常感激收集性能快照然后发给我们。
您是否考虑过介绍重新授予和其他教育深度潜水视频？
我们经常在会议和用户团体上公开谈论我们的产品。我们总是试图解决完整的体验规模，从从未听说过ReSharper或Rider的初学者，到中级和高级用户。我们的目标是教会每个人新的东西!其中一些演讲在知名视频平台上公开。我们还保持net指南在我们的网站和推特提示通过@resharper.和@JetBrainsRider．如果你正在加入一个用户组，请随时联系我们，我们可以组织一次(虚拟)访问!
是否有计划在某些时候将ML纳入重新赶回货物？
我们并没有在ReSharper中引入任何ML功能的计划，但是我们正在Rider中进行这方面的工作(因为IntelliJ平台已经支持各种语言的ML完成)。希望在2021.1年会有新版本发布，敬请期待!
关于骑手的问题
会有一个社区版的Rider吗?
目前，我们没有计划在不久的将来发布骑手的社区版本。与此同时，您可能想查看我们的免费许可计划对于学生，教师，OSS维护者，用户组和许多其他人。此外，骑手EAP（早期访问计划)应该在二月份开。此外，每晚构建是免费的。
是否有计划返回骑手的UI / UX？
自2017年8月Rider发布以来，我们实际上对UI做了很多更新。我们已经更新了默认的主题，删除了许多企业灰色，平滑了UI，并替换了整个图标集。事实上，UI现在支持自定义主题，许多都可以作为插件使用(了解更多）.Rider还有几个编辑器配色方案，它们也可以作为其他ide的插件使用。
我们为Windows引入了自定义绘制标题栏，减少了垂直空间的浪费。2020.3版本引入了一个新的、更简单的Welcome对话框，我们对此进行了讨论IntelliJ博客上的一篇文章，我们最近重做了版本控制工具Windows，以更好地利用垂直和水平布局，包括把diff Windows作为一个编辑器选项卡。我们甚至创造了自己的字体单核细胞增多症的编辑器。
默认情况下，只有一个用于新用户的工具栏，以及导航栏。默认情况下显示的唯一工具窗口是解决方案资源管理器，并且没有更多的工具窗口，而不是我们的任何其他IDE中的窗口。可以从键盘中显示，隐藏和调整所有工具窗口，并从键盘调整，它们可以移动到IDE中的不同位置。它们可以对接，固定或浮动，为多显示器设置提供一些支持，我们正在积极努力提高这种经验，包括拖放对接支持。我们最近介绍了更好支持拖放编辑器选项卡制作标签组。
Rider团队在上下文菜单上投入了大量的精力，我们正在努力保持大小和功能之间的平衡，特别是在编辑器和解决方案资源管理器中。
长话短说，我们一直在关注Rider和其他IntelliJ产品的UI/UX，我们希望IDE既好看又好用。以Rider为例，我们尝试将Alt+Enter菜单作为大多数Rider功能的主要入口点。例如，您总是可以使用Alt+Enter来获得导航、重构和生成菜单，或者您可以直接开始键入来搜索操作。
您对Rider的长期(2-3年)愿景是什么?
虽然很难对这样一个快速增长和变化的市场做出3年的预测，但我们已经确定了我们希望产品发展的几个方向:一般的跨平台。net开发;web开发与ASP。净和ASP。核心网;云。net开发;手机开发，特别是Xamarin;当然，还有游戏开发。对于每一个方向，我们都在仔细调查市场，最常用的技术，典型的开发人员工作流程和方法，我们正在尽最大努力在产品中支持最基本和最广泛的应用。这有助于我们构建我们的路线图，我们很高兴与我们的博客读者分享在这里．
我们什么时候能看到Windows版本的Rider使用。net Core后端?
我们希望在今年发布它。我们已经有了一个可以工作的原型，但是还有一些技术问题还没有解决(例如，我们应该支持WinForms和WPF等只支持windows的技术，用CrossGen替换NGen等)。乐观的估计是Rider 2021.2，但仍可能推迟到2021.3。
我们什么时候可以预期骑手在Apple Silicon M1芯片上运行？
去年，我们在macOS和Linux上从Mono迁移到。net Core，主要原因是性能和稳定性关于迁移的博客文章）.要在M1上完全本机模式运行骑手，我们必须等到.NET核心能够在这些CPU上运行（假设JVM部件已准备好）。
目前我们正在考虑准备某种中间构建，其中前端流程将运行在M1上，后端流程将运行在Rosetta 2上(假设后端流程的性能对IDE性能的影响不像前端那么重要)。我们是否会公开这次实验的结果完全取决于它的稳定性，以及Rosetta 2多久能运行。net Core程序而不出现重大问题(看起来苹果正在努力;看到细节）.
欢迎订阅跟踪问题我们将在那里发布任何新闻。
关于对Rider的原生WSL2支持的想法?
对WSL 2的支持相当复杂。本质上,它需要一个完整的本地开发经验,但是当存储代码和远程机器上运行的进程有自己的文件系统和软件(Git和. net SDK,包括MSBuild我们通常主机在我们这边),以及诸如码头工人。
我们正在慢慢地朝着这个目标前进，但我们不希望它在下一个2021.1版本中出现。
什么时候在。net Core的Rider中加入XAML支持?
我们目前重建XAML预览器平台准备好进行将来的变化。在2021.1中，我们预计为.NET框架项目的明显XAML预览器，而且我们计划为.NET核心释放一个预览器。这是一个很长的过程，因为技术挑战（直接将整个窗口直接进入我们的UI并不容易将整个窗口集成在一起），但我们现在正在努力。
对c++支持什么时候登陆Rider有什么计划吗?
我们现在有虚幻引擎骑士为骑车者带来C ++和UE特定支持。主要目标是游戏开发，因为我们的主要C ++ IDE仍然是克隆。但是，如果您有一个MSBuild项目并希望某些工具替换VS的工具，则骑手将为您工作，您可以使用它。
虚幻引擎的生产准备好骑手的任何ETA？
我们现在正在努力将Rider带到macOS(大部分已经移植)和Linux(这方面的工作才刚刚开始)。我们还试图从供应商那里获得控制台的sdk和开发工具包。这个过程需要花费大量的时间和精力，不幸的是，它阻碍了Rider对主机的支持。我们需要后者去研究《Rider》与主流主机整合的机会。在正式发布之前需要解决的另一个主要问题是调试器的质量(这是我们自己在LLDB上实现的)。一旦我们对所有这些都感到满意，我们就可以准备发布了。我们希望它能在2021年实现，但目前我们不能提供一个估计。
将dotMemory和dotTrace引入Linux和macOS的计划是什么?
分析器应该在骑手或命令行中使用。检查快照是另一个故事。跨平台UI为此正在开发的．
DotPeek会成为跨平台吗？
它已经是，以骑手的形式．当然，您需要打开一个项目/解决方案，但是dotPeek的大部分功能已经存在了。
关于JetBrains .NET团队的问题
.NET团队有多大？
我们目前在我们的.NET部门中有131名成员，其中包括来自Resharper，Rider，DotMemory，DotPeek，Dottrace和Dotcover的团队，以及各种在开发，QA，营销和宣传方面的位置。由于我们的工具很整合，因此没有明确的边界。不同的团队之间的沟通经常发生。例如，我们的骑手开发人员与Intellij团队密切合作，我们的Dottools成员有助于在我们的IDE中的整合。
您使用的是什么进程（Scrum，Kanban，其他东西）？
每个团队都对自己的产品负责，包括其开发过程。团队可能会使用他们认为工作的任何方式。也就是说，在.NET部门，我们通常会有一次计划会议一次。在特定任务的发展中的重要里程碑通常在与整个团队的专用会面中公开讨论，每个团队都可以提出他们的想法。
这些语言是.NET团队直接维护的代码库是由？
大多数重新哈尔和骑手的后端代码是用C＃写的。我说它是码比的85％。为狗造出涉及VB.NET支持的一些代码，在VB.NET中编写，C ++支持是在托管C ++中编写的。同样，F＃插件是用F＃写入的。
骑士的前端（集成到Intellij Idea的部分）是用Kotlin编写的。Leveldb周围的C ++中有一些本机代码（我们用于缓存的数据库）和分析器。
处理探查器和dotcover的处理仪器的代码是纯C ++，但观众和数据处理是用C＃和WPF编写的。我们正在重写Avalonia中的一些观点，以便在未来拥有跨平台的探查器的UI。
您是否与其他产品共享功能？如果是这样，其他团队的工作有多少和如何影响你？
我们共享了大量基于IntelliJ平台的不同ide的功能，如IntelliJ IDEA、Rider、WebStorm、GoLand、DataGrip等等。它们都构建在开源IntelliJ平台上，IntelliJ平台为构建IDE提供了一个核心框架——编辑器、对项目系统的支持、语言解析和索引、检查、Alt+Enter重构、调试和加载更多内容。
大多数功能都是插件，负责特定IDE的团队可以自由捆绑他们想要的插件。这对我们来说是一个很好的解决方案，因为我们可以共享功能，我们可以拥有专注于特定功能的团队，甚至在整个IDE上，但可以在所有基于Intellij的IDE中共享功能集。这里的一个很好的例子是数据涂料。这是一个伟大的独立产品，但它也是一个插件，这意味着骑手（以及许多其他IDE）可以捆绑它并提供一流的集成数据库工具。
此外，我们对WebStorm的Web开发有一个很好的IDE，并且骑手可以免费获得伟大的Web功能，允许骑手团队专注于核心骑手功能，如.NET集成等。说到Android Studio，骑手可以从官方Android IDE中拉到Android功能，以支持Xamarin开发。
与其他团队合作也很顺利。JetBrains拥有非常扁平的结构，几乎没有官僚主义。这意味着与其他团队进行交流、给出反馈或请求特性非常容易。事情并不总是完美的——我们仍然会遇到重大的变化和其他的小问题，但我们会尽最大努力将这些问题最小化。
由于其架构，骑手比其他ides更困难。基于Intellij平台的大多数IDE以同样的方式构建支持。项目模型，语言解析器，检查，调试器以及更多都以Java和Kotlin编写，并在基于JVM的Intellij应用程序中运行。骑手使用Intellij平台作为前端，但使用Resharper作为.NET语言引擎。所以骑手在Intellij的方面有很多门面，它与Resharper作为一个无头服务进行交谈（您可以阅读更多关于此架构的信息在这里）.但这意味着在Intellib方面有较少的信息，以便能够做一些有趣的事情。例如，彩虹括号插件使用文件的语法树来查找匹配的括号并以每个范围的颜色突出显示它们。很长一段时间，Intellij侧没有一个语法树，所以无法为C＃实现这一点。最近版本的骑手包含了一个简单的语法树，所以现在可以实现，但仍然存在一些功能，因为语法树没有完全特色。它两种方式 - 两种方式 - 骑手的一些功能都是由重新授予提供的，因此它们不可用其他IDE提供。当然，智慧和重新托克斯都提供的甚至类似的特征也可能是非常不同的架构，这意味着它很难带来功能。这种情况的一个例子是结构搜索和替换，它在Resharper中不同于IntelliJ平台的次数不同。
您如何决定下一个功能或错误的功能？单个开发人员可以在多大程度上决定自己何心？
这可能会因团队而异，但一般来说，开发人员在他们想要完成的任务上有很大的自由。除了严重的倒退，每个开发人员都可以自己选择下一步想要实现的内容，并在没有任何正式批准过程的情况下开始修复bug或实现特性。然而，可能会影响性能的大型特性会呈现给团队，并在它们进入产品之前进行讨论。还有一些语言支持任务必须在语言的下一个版本发布之前完成，无论是否有开发人员想要拥有某个语言特性。这样的任务通常在完成下一个语言版本的特性集并根据开发人员的工作负载和受该语言特性影响的特定领域的专业知识分配给开发人员时进行讨论。
我们希望您喜欢我们的AMA会议！请记住，我们的博客和社交媒体频道总是对问题开放，因此不要犹豫与我们联系。如果您正在遇到问题，请在Twitter上联系我们，文件a支持机票，并使用我们的问题跟踪器．我们在这里帮助！
