Visual Studio 2017 的实时单元测试

[原文发表地址]: Live Unit Testing in Visual Studio 2017 RC [原文发表时间]: November 18, 2016 我们非常自豪地在Visual Studio 2017引进了一个新的特性叫实时单元测试!这个特性会使您很容易的维护产品质量和测试覆盖率,并且将生产力提升到一个全新的水平。想象下您正在一个完全不熟悉的代码库中修补一个缺陷,在您为了修补这个缺陷编辑完代码后,根据实时单元测试您可以立马知道系统受影响的部分。有了这个反馈,跟原来相比,当您修改代码时将会带给您额外的信心,让您的工作更富有成效,甚至让您喜欢上修复缺陷和编写单元测试,何乐而不为呢! 当您编辑代码时,实时单元测试在后台自动运行受影响单元测试,并在编辑器中实时显示结果和代码覆盖率。除了对您的更改会对现有测试产生的影响提供反馈之外,您还可以即时获得有关您添加的新代码是否已经被一个或多个现有测试覆盖的反馈。这会很好的提醒您在错误修复或者添加功能时编写单元测试。 实时单元测试存在于Visual Studio 2017的企业版本中,它可用于面向.NET Framework的C#和VB项目。它使用VB和C#编译器在编译时测试代码。接下来,它对测试代码运行单元测试以生成数据,分析该数据以了解哪些测试覆盖了哪些代码行。 然后它使用这些数据运行那些受到给定编辑影响的测试,提供对编辑器本身的结果的即时反馈。 随着更多的编辑或更多的测试被添加或删除,它不断地更新用于识别受影响的测试的数据。 如何启用实时单元测试 启用实时单元测试,通过打开顶层菜单栏中的Test命令,然后选择对应的命令来启用它,如下图所示。   在Visual Studio里,实时单元测试适用于三个流行的单元测试框架, 即MSTest,xUnit和NUnit。使用这些时,您需要确保适配器和框架符合或超过以下给出的最低版本。请从现有项目中删除旧的适配器和测试框架引用(确保您删除的是 “Microsoft.VisualStudio.QualityTools.UnitTestFramework”的引用),并添加新的,如果实时单元测试不能正常工作。 你可以从NuGet.org得到所有这些。 对于xUnit,您将需要xunit.runner.visualstudio 2.2.0-beta3-build 1187和xunit 2.0版本(或更高版本) 对于NUnit,您需要NUnit3TestAdapter 3.5.1版本和NUnit版本3.5.0(或更高版本) 对于MSTest,您将需要MSTest.TestAdapter 1.1.4-预览版和MSTest.TestFramework 1.0.5预览版(或更高版本)  体验实时单元测试 启用后,实时单元测试可帮助您快速查看您所编写的代码是否被覆盖,以及覆盖该代码的测试是否通过,而无需离开编辑器。 单元测试结果和覆盖可视化在代码编辑器中逐行显示,如下面的示例图所示: 如果一行可执行代码被至少一个失败的测试覆盖,实时单元测试将用红色“×”来标识它。 如果一行可执行代码只被通过的测试覆盖,实时单元测试将用绿色“✓”来标识它。 如果一行可执行代码没有被任何测试覆盖,实时单元测试将用蓝线来标识它。 实时单元测试提供的实时代码覆盖和测试结果信息消除了手动选择和运行测试的负担。 实时反馈还用于当您的更改破坏了程序时立即通知您, 如果内嵌可视化结果从绿色“✓”变为红色“×”,您就知道您破坏了一个或多个测试。 在任何时间点,您可以将鼠标悬停在“✓”或“×”上,可以查看指定代码影响了多少处测试,如下图所示: 你可以通过点击“✓”或“×”,查看指定代码影响了哪些测试,如下图所示。 当悬停在工具提示框中的错误的代码行上,它会扩展开提供更多信息,以便更好地了解故障,如下图所示。 此外,您可以通过点击工具提示框中的信息直接导航到具体错误的代码行。 然后,通过失败的测试信息提示,您可以轻松地调试产品代码,进行编辑,并继续,然而实时单元测试仍在后台运行。 无需停止和重新启动实时单元测试进行调试、编辑等。…

0

不断壮大的Visual Studio家族产品

[原文发表地址]: The expanding Visual Studio family of products [原文发表时间]: November 16, 2016   我们的核心愿景是 “Any Developer, Any App, Any Platform”。 对于我们的Visual Studio系列产品,我们致力于为您带来最强大和最高效的开发工具和服务,使每一位开发人员可以开发出跨Windows、 iOS、Arndriod 以及 Linux 平台的移动为先和云为先的应用程序。 我们现有的Visual Studio系列产品包括了市场上最全面的开发以及应用程序生命周期工具。业界领先的IDE,轻量级代码编辑器 – Visual Studio Code,使用Visual Studio Team Foundation Server和Visual Studio Team Services的内部部署以及基于云计算的团队协作服务。此外,我们还免费提供Visual Studio Dev Essentials服务和Visual Studio 订阅。 今天,在纽约的Connect(); 2016 大会上, 我们宣布了Visual Studio 2017 RC 和TFS 2017 RTM。我也很高兴看到Visual Studio…

0

Visual Studio2017 起始页功能简介

[原文发表地址]: Harness the Power of the Redesigned Start Page [原文发表时间]: November 29, 2016 我们的Visual Studio 2017,具有快速安装、性能更好和效率更高的特点。效率更高的体现之一就是重新设计的起始页,新的起始页会帮助您更快的进行编码和开始工作。   最近使用列表 我们已经从大家的反馈中了解到MRU(最近使用列表)是起始页最有价值的一部分,所以我们觉得是时候给它应有的重视了。为了帮助您快速找到你想要找的,现在每个MRU项目显示一个图标,来表示它是一个项目、解决方案或文件夹、本地项目文件路径和一个远程项目尚未在磁盘上的远程URL。随着对打开文件夹功能的支持,我们也添加了对最近打开的文件夹的支持。新的MRU也会按日期、历史记录和所固定的项目来分组,让您可以通过MRU轻松访问那些重要的项目。 为了帮助您可以在多个机器上工作来提高效率,我们还在MRU增加了同步功能。如果您克隆了一个存储库,例如Visual Studio 团队服务或GitHub,Visual Studio会将这个存储库显示到您同一帐户的任何Visual Studio实例。然后,您可以从MRU选择要克隆的项目,在该代码库继续你的工作。 显示固定的远程存储库、文件夹和项目的MRU 新建项目 无论你是初次使用 Visual Studio,还是经验丰富的用户,很多时候你都需要创建一个新的项目。经我们调查研究显示,“新建项目…” 命令是起始页最常用的功能之一,但在与你们很多人沟通之后发现,你们在操作过程中经常会创建一些相同的项目。为了加快速度,起始页现在允许你搜索你想要创建的特定的项目类型。有了这一变化,用户将不再需要点击新建项目就可以找到想要的项目类型。除此之外, 起始页将会记录并显示你最近创建的项目,并允许你直接在起始页新建项目,省略了在新建项目对话框中进行查找和选择的步骤。如果用户登录到Visual Studio, 此列表将会同步用户设备中的项目模板。     近期项目模板         搜索web项目模板 打开 无论你的代码是在本地、在TFS服务器上、在VSTS上或者分享到GitHub。我们想要您更容易地查找、下载和打开该工程。 我们新增了打开文件夹功能,同时保留了打开工程/解决方案的命令,使您在有或者没有VS解决方案文件时都能打开一个代码库。 对于在TFS 上的或者托管在 VSTS 上的代码,都支持开箱即用。你可以简单的通过点击”签出自” 标题下的Visual Studio Team Services来克隆存储库。这部分也是第三方可扩展的。GitHub 是服务提供商之一,并使用了这个扩展。对于那些已经安装了更新的 GitHub 扩展的用户,你会注意到 GitHub 会和VSTS一起出现。我们也正在努力加载更多的服务提供商,这样不管你的项目在什么服务上,就都可以轻松的连接到您的代码了。…

0

Visual Studio”15“的内存溢出崩溃锐减

[原文发表地址]: Reduced Out of Memory Crashes in Visual Studio “15” [原文发表时间]: October 12, 2016   这是Visual Studio “15” Preview 5中关于性能改善五部分系列中的第三篇博客。前两篇博客介绍的是在Visual Studio “15”中启动更快和项目解决方案加载时间更短。 Visual Studio集多种功能于一身,数百万的开发人员都依赖于它进行高效的工作。支持如此多的功能,而且随着开发者期望的响应速度的提高,内存消耗就有所增加。然而,在Visual Studio 2015中,在某些情况下的内存使用量过大。这导致了一些不利的影响,例如内存溢出崩溃,UI反应迟缓。我们收到了大量用户对于这些问题的反馈。在VS “15”中我们正在解决这些问题,同时不会削弱Visual Studio丰富的功能和性能。 我们正在优化Visual Studio的很多功能,这篇文章介绍了三个具体领域的进展: JavaScript与 TypeScript语言服务,调试器符号文件加载,VS中的Git支持。在本文中我将对每一个测试场景比较以下两个指标,来展示我们所取得的进展: 峰值虚拟内存: Visual Studio是一个32位的应用,这意味着消耗的虚拟内存可以达到4GB。超过上限的内存分配会导致Visual Studio出现内存溢出错误(OOM)而崩溃。峰值虚拟内存是一个用来度量进程的内存将如何接近所限制的4GB的指标,或者换句话说,可以度量一个进程是如何接近崩溃的指标。 峰值私有工作集:一个包含了进程执行的代码或进程涉及的数据的虚拟内存的子集需要被放在物理内存中。“工作集”是这样的物理内存消耗的度量标准。这种工作集的一部分称作“私有工作集”,是属于一个给定进程的内存,并且是单独属于这个进程的。因为这样的内存不是进程间共享的,他们在系统上的消耗相对较高。本文的测量数据包括了Visual Studio (devenv.exe)的峰值私有工作集和相关的附属进程。   JavaScript语言服务 超过三分之一的Visual Studio开发人员定期编写JavaScript (JS),使JS语言服务成为在相当数量的Visual Studio会话中需要加载的一部分。JS语言服务提供的功能如智能感知、代码导航和一些使JS编辑高效的功能。 为了支持这种生产力特性并且确保他们响应迅速,语言服务消耗了不少的内存。内存的使用量取决于解决方案的特性、工程的数量、文件的数量以及文件大小。此外,JS语言服务通常会和另一种语言服务一起被加载,例如C#,这会增加进程的内存压力。因此,提高JS语言服务的内存占用对减少VS中内存溢出崩溃是至关重要的。 在VS “15”中,我们想要确保Visual Studio可靠性不会被JS代码造成的内存消耗而不利地影响。为了实现这个目标而不影响JavaScript的编辑体验,在VS“15” Preview 5中我们已经将整个JS语言服务移动到一个可以与Visual Studio进行通信的附属进程Node,js中。我们还合并了JavaScript和TypeScript语言服务,这意味着我们通过实现两种语言服务被同时加载来减少内存。 为了测量对内存的影响,我们在以下场景中比较了Visual Studio 2015…

0

Visual Studio”15“的内存溢出崩溃锐减

[原文发表地址]: Reduced Out of Memory Crashes in Visual Studio “15” [原文发表时间]: October 12, 2016   这是Visual Studio “15” Preview 5中关于性能改善五部分系列中的第三篇博客。前两篇博客介绍的是在Visual Studio “15”中启动更快和项目解决方案加载时间更短。 Visual Studio集多种功能于一身,数百万的开发人员都依赖于它进行高效的工作。支持如此多的功能,而且随着开发者期望的响应速度的提高,内存消耗就有所增加。然而,在Visual Studio 2015中,在某些情况下的内存使用量过大。这导致了一些不利的影响,例如内存溢出崩溃,UI反应迟缓。我们收到了大量用户对于这些问题的反馈。在VS “15”中我们正在解决这些问题,同时不会削弱Visual Studio丰富的功能和性能。 我们正在优化Visual Studio的很多功能,这篇文章介绍了三个具体领域的进展: JavaScript与 TypeScript语言服务,调试器符号文件加载,VS中的Git支持。在本文中我将对每一个测试场景比较以下两个指标,来展示我们所取得的进展: 峰值虚拟内存: Visual Studio是一个32位的应用,这意味着消耗的虚拟内存可以达到4GB。超过上限的内存分配会导致Visual Studio出现内存溢出错误(OOM)而崩溃。峰值虚拟内存是一个用来度量进程的内存将如何接近所限制的4GB的指标,或者换句话说,可以度量一个进程是如何接近崩溃的指标。 峰值私有工作集:一个包含了进程执行的代码或进程涉及的数据的虚拟内存的子集需要被放在物理内存中。“工作集”是这样的物理内存消耗的度量标准。这种工作集的一部分称作“私有工作集”,是属于一个给定进程的内存,并且是单独属于这个进程的。因为这样的内存不是进程间共享的,他们在系统上的消耗相对较高。本文的测量数据包括了Visual Studio (devenv.exe)的峰值私有工作集和相关的附属进程。   JavaScript语言服务 超过三分之一的Visual Studio开发人员定期编写JavaScript (JS),使JS语言服务成为在相当数量的Visual Studio会话中需要加载的一部分。JS语言服务提供的功能如智能感知、代码导航和一些使JS编辑高效的功能。 为了支持这种生产力特性并且确保他们响应迅速,语言服务消耗了不少的内存。内存的使用量取决于解决方案的特性、工程的数量、文件的数量以及文件大小。此外,JS语言服务通常会和另一种语言服务一起被加载,例如C#,这会增加进程的内存压力。因此,提高JS语言服务的内存占用对减少VS中内存溢出崩溃是至关重要的。 在VS “15”中,我们想要确保Visual Studio可靠性不会被JS代码造成的内存消耗而不利地影响。为了实现这个目标而不影响JavaScript的编辑体验,在VS“15” Preview 5中我们已经将整个JS语言服务移动到一个可以与Visual Studio进行通信的附属进程Node,js中。我们还合并了JavaScript和TypeScript语言服务,这意味着我们通过实现两种语言服务被同时加载来减少内存。 为了测量对内存的影响,我们在以下场景中比较了Visual Studio 2015…

0

Visual Studio “15”响应速度更快

[原文发表地址]: Improved overall Visual Studio “15” Responsiveness [原文发表时间]: October 14, 2016   这是包含Visual Studio “15” 性能提升5部分系列的最后一篇博客了。 这个系列中包含了下边的内容: · Visual Studio “15” 启动更快了 · VS“15”项目解决方案加载时间更短 · VS“15”中由于内存溢出产生的崩溃现象减少了 · VS“15”让C++工程更快 · VS “15” 响应速度更快 在这篇博客中我们会着重介绍下在VS “15” 预览版5中我们所做的一些让Visual Studio在日常使用过程中 反应更加灵敏的改进。首先,我们先讲一下在调试性能、Git源代码管理和XAML编辑方面的改进,以及怎样通过管理插件来改进你的输入体验。   调试更快速并且不会因为编辑造成延迟 在Visual studio 2005中,我们引进了WPF工程、windows窗体工程和可管理控制台项目的托管进程,通过在后台启动一个可用于下一个调试会话的进程,来使“开始调试”速度更快。该功能会导致Visual Studio在按下“停止调试”时暂时性的几秒钟内无响应或者是只能在停止调试会话之后才能使用Visual Studio。 在预览版5当中,我们关闭了托管进程,并且优化了“开始调试”,这就使得如没有托管过程一样快速,而对于从未使用过托管过程的项目(例如ASP.NET,Universal Windows和C ++)来说可能会更快。例如,下边是一些我们在测试机器上所统计的UWP照片共享应用程序、一个针对于可视化的C++应用程序和一个简单的WPF应用程序的启动时间对比图: 为了实现以上提升,我们在开始调试路径上优化了初始化诊断工具窗口和智能追踪(默认情况下会在每一个调试会话开始的时候显示)的相关时间花费。我们修改了智能追踪的初始化模式,这样的话它就可以在其他调试过程和应用启动的时候被初始化。另外,我们通过智能追踪记录和Visual Studio进程在断点处停止时的交互的方式消除了几个低效率进程。 我们还删除了几个与诊断工具窗口相关的必须在Visual Studio UI主线程上同步运行代码的后台线程。 这使得我们可以异步进行ETW事件收集,从而在重新启动调试时,不必等待旧的ETW会话完成。   Git.exe…

0

Visual Studio “15”响应速度更快

[原文发表地址]: Improved overall Visual Studio “15” Responsiveness [原文发表时间]: October 14, 2016   这是包含Visual Studio “15” 性能提升5部分系列的最后一篇博客了。 这个系列中包含了下边的内容: · Visual Studio “15” 启动更快了 · VS“15”项目解决方案加载时间更短 · VS“15”中由于内存溢出产生的崩溃现象减少了 · VS“15”让C++工程更快 · VS “15” 响应速度更快 在这篇博客中我们会着重介绍下在VS “15” 预览版5中我们所做的一些让Visual Studio在日常使用过程中 反应更加灵敏的改进。首先,我们先讲一下在调试性能、Git源代码管理和XAML编辑方面的改进,以及怎样通过管理插件来改进你的输入体验。   调试更快速并且不会因为编辑造成延迟 在Visual studio 2005中,我们引进了WPF工程、windows窗体工程和可管理控制台项目的托管进程,通过在后台启动一个可用于下一个调试会话的进程,来使“开始调试”速度更快。该功能会导致Visual Studio在按下“停止调试”时暂时性的几秒钟内无响应或者是只能在停止调试会话之后才能使用Visual Studio。 在预览版5当中,我们关闭了托管进程,并且优化了“开始调试”,这就使得如没有托管过程一样快速,而对于从未使用过托管过程的项目(例如ASP.NET,Universal Windows和C ++)来说可能会更快。例如,下边是一些我们在测试机器上所统计的UWP照片共享应用程序、一个针对于可视化的C++应用程序和一个简单的WPF应用程序的启动时间对比图: 为了实现以上提升,我们在开始调试路径上优化了初始化诊断工具窗口和智能追踪(默认情况下会在每一个调试会话开始的时候显示)的相关时间花费。我们修改了智能追踪的初始化模式,这样的话它就可以在其他调试过程和应用启动的时候被初始化。另外,我们通过智能追踪记录和Visual Studio进程在断点处停止时的交互的方式消除了几个低效率进程。 我们还删除了几个与诊断工具窗口相关的必须在Visual Studio UI主线程上同步运行代码的后台线程。 这使得我们可以异步进行ETW事件收集,从而在重新启动调试时,不必等待旧的ETW会话完成。   Git.exe…

0

Visual Studio “15” Preview 5 发布公告

[原文发表地址]: Announcing Visual Studio “15” Preview 5 [原文发表时间]: October 5, 2016   今天我们发布了Visual Studio “15” Preview 5版本。对于Preview 5版本, 我想主要介绍下性能方面的改进,在接下来的几天,我们还会有后续的博客来描述我们已经可以看到的性能提升。我打算主要说明下那些已经可以提高效率的改进点。 启动安装程序,并阅读下文,你也可以获取发布说明来了解详情。   性能与内存效率的大改进 我想根据这个并行对比视频,给你展示所有的性能改进。这个视频是比较打开 Visual Studio 并加载整个.NET 编译器平台”Roslyn”的解决方案,Visual Studio ’15’ 用时30秒,而Visual Studio 2015用时60秒。 更快的加载时间是“轻量级工程加载以及按需求扩展加载”双管齐下改进的结果。下面是一些在Preview 5中的关键性能的提升: 通过“轻量级解决方案加载”选项来缩短解决方案加载时间: 工作在超过100多个项目的解决方案中,并不意味着需要在一定时间内操作所有的文件或项目。VS “15”提供了在不需要等待所有工程加载完毕时就可编辑和调试的功能。你可以在Preview5的托管工程中尝试一下这种功能,可以通过工具-> 选项 ->项目和解决方案,勾选“轻量级解决方案加载”。 通过按需加载扩展来更快的启动:方法很简单:当需要扩展时再加载,而不是在打开VS的时候就加载。在 Preview 5中,我们开始这样做了,已经改变了Python和Xamarin扩展为按需加载,并正在改变我们提供的所有Visual Studio扩展,以及由第三方扩展供应商所提供的扩展到这种模式。想知道哪些扩展影响了启动,解决方案加载等性能呢?你可以在帮助->管理Visual Studio性能中查看这些信息。你开发过扩展吗?我们将发布指导来帮助扩展开发人员将扩展改为按需加载。 将子系统从VS主进程移动到独立进程: 我们移动了一些内存密集型任务,例如 Git 源代码管理、JavaScript 和TypeScript语言服务,以便分离进程。这就杜绝了那些较差的体验,如由于代码运行Visual Studio的程序造成的延时,或者因32位的处理器中主程序已有达到约4 GB的内存上限造成的Visual Studio变得缓慢或者崩溃。在未来的版本中,我们将继续把组件移动到进程外。 对C++项目,更快的加载项目,编码,调试: 我们可以更快的加载C++项目,查看这个显示改进的视频。你可以通过从工具->选项->文本编辑->C/C++->实验,将“启用更快的项目加载”的值设置为True来启用它。我们也改进了我们的链接器和PDB加载库,使得增量生成工程以及调试时更快,同时在调试的时候所消耗的内存也明显减少了。 使用Git、调试工程和编辑XAML代码时速度有所提升:通过从libgit2切换到git.exe,我们提高了源代码管理操作的速度。我们也通过优化初始化时间和其他与IntelliTrace相关的时间,以及诊断工具窗口,还删除了编辑XAML文件时出现的几次延迟。从而提高了调试性能。…

0

Visual studio “15” 中解决方案加载时间更短

[原文发表地址]: Shorter Solution Load Time in Visual Studio “15” [原文发表时间]: October 11, 2016   Selma之前分享了一些使visual studio “15”启动比以前更快的方法。今天,我会讨论visual studio “15” 中的一个新功能叫做轻量级的加载解决方案。这个功能极大减少了解决方案加载时间,所以你可以更有效率更快地使用IDE。   轻量级加载解决方案 当启用轻量级加载解决方案,Visual Studio 不会完全加载项目,除非你开始使用它。许多常见的任务,例如通过您的代码库导航,编辑代码,和编译您的项目将不需要加载所有项目。 为了了解在真实的场景中它是如何工作的,我们在容量有限的 Visual Studio “15”preview 4 上发布了轻量级加载解决方案。目前看来,这些性能改进效果还是不错的: 在推出这个有限的功能之后,我们发现解决方案加载时间加快了两到四倍。 此功能的最终目标是使您在IDE中更加高效的工作。使用轻量解决方案加载的开发者们能够在浏览或者编译他们的代码时快1到2分钟。我们也期待在Preview5 中这一特性能够被更完整地发布。   试试它 轻量级的解决方案加载在Preview5 上并不是默认启用的,但我们想鼓励开发者们在中型到大型的、或托管解决方案中尝试这一功能并给予反馈。启用轻量级的解决方案加载,可以在导航菜单中选择工具->选项,然后选择项目和解决方案->通用,再勾选页面底部的‘轻量级解决方案加载’: 一旦启用了轻量级解决方案加载,你可以像往常一样打开并操作你的项目和解决方案。设置将在你下次加载解决方案的时候生效,没有必要去重启IDE。 在Preview5中轻量级解决方案加载主要作用于托管项目。若你在处理中型或大型的C#或VB的解决方案,我们强烈建议你试用这一新特性。你也能够打开C++或其他项目类型的混合解决方案——但请记住,对于其他类型的项目(更多信息见下文*)而言,目前还不是所有性能的提升都是可用的。 当轻量解决方案打开后,你或多或少能够像往常一样继续你的工作,只是会更快一些。特别地,还有一些事你可以试试: 用Navigate to(Ctrl+,)浏览你的代码库定位,查找声明定义(F12),查找文件,或查找所有引用 重构代码或内联重命名 生成或调试您的解决方案 你可能会注意到一些操作花了一些时间在后台加载项目数据。 请注意,轻量级解决方案负载仍然在试验中,所以它仍有一些不足之处: 如果一个关于项目的功能从IDE中丢失了,请尝试在解决方案资源管理器中扩展项目。如果有任何不能正常工作的情况请告知我们。 NuGet包恢复至今仍未与轻量级解决方案负载集成,我们建议在打开功能之前恢复包打开之前的功能或用命令行恢复。 除非一个项目完全被加载,否则测试浏览器不会看到测试结果。 如果你需要在一个解决方案中重定向或升级所有项目,禁用轻量级解决方案负载效果会更好。 *虽然在Preview5中轻量级解决方案负载作用于托管项目,如果你是一个C++开发者 也请不用担心,在未来的Preview5中有很多关于C++的性能改进,——在周四查看本系列的第四部分可以获取更多细节。在将来的版本中,这些改进将纳入轻量级解决方案加载。   请给我们反馈!…

0

Visual Studio “15”启动更快了

[原文发表地址]: Faster Visual Studio “15” Startup [原文发表时间]: October 10, 2016   正如John上周三在预览版5发布的博客中提到的,我们在这个版本中进行了大量的性能改进。这是包含Visual Studio “15” 性能改进的五部分系列的第一部分。 今天,我将向您介绍一系列我们为改进Visual Studio启动体验而进行的投入,主要包括以下方面: 使用我们的新性能中心,您如何确定所使用的扩展或者工具窗口是否影响了启动、解决方案加载或代码编辑等方面的体验。当然,还有如何优化它。 如何使用按需加载方法将扩展移出启动路径,优化和推迟缓存初始化,来有助于我们改善启动时间。 近年来,随着Visual Studio用户群的增长,在Visual Studio中也融合了一些合作伙伴的技术。 不幸的是, 由于这些功能在启动时会自动加载,这极大地影响了Visual Studio的启动时间。 下面是一个示例,显示了Visual Studio启动时间在启动加载扩展时,如何轻松地减慢50%。   Visual Studio启动包含什么? 有三个不同的Visual Studio 启动类型: 首次启动:安装完成后第一次启动Visual Studio。 第一次启动Visual Studio比其他启动要慢得多,因为Visual Studio环境配置了各种缓存和预构建的表。 正常启动:我们将在第一次启动后,后续的Visual Studio启动,称为正常启动; 此类启动不包括调试实例,或使用命令行参数启动的实例,以及之前安装的扩展或更新的实例。80%的Visual Studio启动都属于正常的启动。 配置更改:在安装扩展或更新后发生的启动。 这些类型帮助我们识别潜在减速的根本原因,有利于进一步调查优化方案。 首次启动的改进 在Visual Studio 2015中,首次的启动包括扫描安装的组件和创建一个配置文件,初始化默认设置,获取用户登录信息,并初始化缓存,如托管扩展框架(MEF),扩展管理器,工具箱以及字体/颜色缓存。 在Visual Studio“15”中,我们已经考虑了每个步骤,以查看哪些可以延期或优化: 我们尝试在Visual Studio 2015中推迟工具箱的初始化,这对于加载时间有积极的影响,于是在Visual Studio“15”中就进行了这种更改。 一些缓存,如字体和颜色缓存不再在第一次启动时初始化。…

0