Visual Studio 2015 Update3 的C++ 编辑并继续

[原文发表地址] C++ Edit and Continue in Visual Studio 2015 Update 3 [原文发表时间] 2016/7/1 我们一直在改进C++的编辑并继续(EnC)功能 自从我们在Visual Studio 2015 发布它之后,EnC使用默认的调试引擎和VC140工具包。我们已经处理了相当多的客户反馈,同时在此基础上,我会在这篇博客中介绍 Update3(下载)和其它有关C++ EnC的最新进展。 快速回顾一下——编辑并继续允许您在调试的时候修改您的代码(举个例子,如果在运行的时候你在代码里发现了一个bug),调试器可以在调试的进程中应用代码的更改,并可以继续使用您的新代码进行调试!这可以帮助加快您的编辑->生成->部署->调试周期。您可以在我们之前的博客里找到更多的信息,同时在这里也有介绍如何使用C++的编辑并继续。 我们在Update3的修复 在静态库中旧代码(错误信息)的EnC: 在静态库中对源文件进行编辑会导致源信息的不匹配以及旧代码会有一个误导的“成功应用代码改变”的消息。目前这个问题已被修复,现在任何旧代码在任何情况下都应该包含一个关于为什么我们不能映射指令指针的警告说明。 在一些比较大的项目中,EnC崩溃/卡住时带有链接/DEBUG:FASTLINK调试信息: 自从链接开关FASTLINK泄露某些信息在obj文件中,而不是整合所有的信息到PDB中后,在运行大程序的时候VS会遇到和EnC有关的内存问题,目前已经解决了这个问题。 C1092错误/C4656警告:我们已经修复了很多臭名昭著的有关于“严重错误 C1092:编辑并继续不支持对数据类型的修改;需要重新生成”的不相关更改的错误。同时,如果你使用/WX(把所有的警告都视为错误)生成,编译器在EnC的时候这些会导致编译错误的误报,也不会发出“警告C4656:…数据类型是新的或已从最新的版本上更改,或者在其他地方被定义的不同” 在EnC上提高“应用代码更改…”的性能:我们已经减少了应用代码更改的时间(即:当你看到“应用代码更改…”的对话框时),并且让它快了3倍。 Update3的断点改变 允许预编译(只在本地):调试选项调试->选项->常规->允许预编译(只在本地)不再支持Visual Studio Update3和默认调试器。对边际性能的改进是之前的设置,没有功能上的影响。 快速EnC参考 C++编辑并继续的需求 生成设置(程序属性) C/C++->常规->调试信息格式:编辑并继续程序数据库(/ZI) C/C++->代码生成->启用最小重新生成:是的(/Gm) 链接器->常规->启用增量连接:是的(/增长的) 任何不兼容的链接器设置(例如/SAFESEH, 或者 /OPT:…)在生成时的都应该导致LNK4075警告(举个例子,由于‘/OPT:ICF’规范而忽略‘/EDITANDCONTINUE’) 调试设置(调试->选项->常规) 启用本地调试并继续 在“编辑并继续”中,任何不兼容的编译器或者链接器都会导致一个错误(举个例子,“‘file.cpp’在‘MyApp.dll’中链接的时候并没有启用“编辑并继续”。确保启用了增量链接,而且,//EDITANDCONTINUE指令是不容忽视的。”) 不兼容的设置和不支持的情况 调试器设置(调试->选项->常规): “要求源文件与原始版本完全匹配:在修改方法时,不选此选项会导致在EnC之后不正确的断点绑定,同时,随着更新3应用此选项的更改,会导致错误“‘要求源文件精确匹配原始版本’在调试选项>选项>中的“设置”需要启用编辑并继续。请检查此选项,然后再试一次。”  “允许预编译(仅限本机)“:在Visual Studio 2015中,默认调试器不再支持这个选项。 Windows 8/8.1 应用商城:这些程序使用VC 120的工具包和C…

0

介绍 Visual Studio 的 Android 模拟器

[原文发表地址]:Introducing Visual Studio’s Emulator for Android [原文发表时间]:2014/11/12 7:31 AM 这篇文章在2015年2月被更新以反映最新的变化。  Microsoft Visual Studio 2015 现已添加Android开发选项:C++,Cordova,以及是用C# 的 Xamarin。当你选择一个Android开发选项,Visual Studio将安装全新的Visual Studio模拟器用作Android应用程序的调试。你也可以点这里查看视频介绍。 在介绍这个新模拟器之前,我们先来聊一聊,为什么需要一个新的Android 模拟器 – 当然,你也可以直接跳到自己感兴趣的部分去阅读:-) Android模拟器存在的必要性 我们知道,模拟器在编程-编译-调试开发周期中,扮演着很重要的角色(甚至比物理设备还重要)。所以我们相信,今天发布的这个模拟器,在开发中是必不可少的。 有了优秀的模拟器,不代表我们就不需要物理设备了。反之亦然,他们之间其实是互补的关系。 下列几种情况,只能用物理设备测试,模拟器派不上用场: 测试代码的性能。虽然模拟器能帮你纠正代码中的错误,但是它无法正确的给出,代码在指定设备上的性能评估。毕竟,我们都希望测试的结果,尽量接近用户实际使用的效果。    测试某些硬件问题。比如,你想测试下游戏的触摸灵敏度,外放的音效,或者调试 OEM 设备的 Bug ,这些测试只能在物理设备上进行。 评估真实的用户体验。譬如,你设计出来的人机交互界面,适不适合用户边走路,边单拇指操作?  除去上面列举的场景,大家应该都会很乐意使用模拟器。因为调试代码通常占用了80%的开发时间,而模拟器为我们大大提高了工作效率。(除非你的模拟器有其他阻塞性问题或者使用限制)。下面是使用模拟器的几个理由: 大部分的测试工作都是用来验证程序的正确性而非性能,并且大部分的代码都与底层硬件无关。所以是用模拟器是极好的。 购买一大堆硬件设备来测试是一件很奢侈的事情(特别是持续不断的购买新机)。大部分的硬件差异可以使用模拟器软件进行配置,比如说屏幕分辨率,不同屏幕的DPI,API级别/平台版本号等等。 使用物理动作来测试程序对传感器输入的反应也是很费劲的,比如说动作变化、地理位置变化或是网络/电池的变化。在这种场景下,选择模拟器来模拟传感器的输入就非常便捷高效,比如说模拟器可以模拟一段旅程中位置的变化,并测试应用程序对地理位置变化的响应。 使用模拟器还有一项而外的便利。管理多个物理连接的USB设备 (一大堆连线和接口) ,是很麻烦的。此时使用模拟器就简单得多,模拟器就是一个运行在电脑上普通的应用层序,除去了物理连接的烦恼,非常便于管理。 所以说模拟器是软件的开发的好伴侣,我们希望把VS的模拟器打造成第一流的。我们从开发者那里收集到现有模拟器的难点,在我们的版本上予以一一击破: 速度慢。这是从Android开发者那排名第一的抱怨。“这个模拟器速度慢极了,严重影响了我的生产率,我还不如用真机测试。”速度慢是不可接受的。使用模拟器应该比使用真机的运行速度更快才是,这样才能提高测试效率。记住一点,我们并不是在测试代码的运行性能,对功能测试来说就是要让模拟器尽可能地跑得快。 与Windows的Hyper-V冲突。很多模拟器在运行时要关闭Hyper-V,或是在使用Hyper-V时,性能反而更糟糕。但使能Hyper-V是大部分开发者的常见配置,频繁重启电脑来开关Hyper-V是不可接受的。 对那些要使用Windows Phone模拟器(基于Hyper-V)的开发者来说就更为苦恼。总不能为因为要测试跨平台的代码,不断的重启和配置电脑设置吧。 额外的购买和安装步骤。如果你已经在使用Visual Studio,那么恭喜你,你不许要再额外购买和安装一款其他的模拟器软件。 更多的费用开销。购买一款卓越的模拟器,也意味着更高的开销,这也是拒绝使用模拟器的一个主要原因。Visual Studio的Android模拟器是附赠的,不需要额外的费用。 简单来说,我们在Visual Studio的Android模拟器解决了以上痛点。废话不多说,下面开始给大家介绍使用VS的Android模拟器的调试方法,我们将从如何选择Android模拟器开始讲起。 用Visual Studio 模拟器调试 Android 程序 无论你用的是哪一种编程模式:用 JavaScript(或 TypeScript)的 Cordova,C++,或是用…

0

在Android上使用Visual Studio 2015调试 C++代码

[原文发表地址]Debugging C++ code on Android with Visual Studio 2015 [原文发表时间]2014/11/12 3:32PM 现在,你将听到令人振奋的消息,Visual Studio 2015支持Android上的C++开发(包括模拟器Android版)。 显然,任何不支持调试的开发体验都是不完整的,因此这意味着Visual Studio 2015支持在调试运行在Android上的C++代码。有了这个新的调试引擎,你会得到以下调试的经验包括(但不限于): F5,输出窗口,断点,单步/跳过/输出,运行到光标,调用堆栈,数据和变量窗口,模块窗口,地址级调试(拆卸,内存,寄存器窗口),线程窗口和并行堆栈以及并行监视窗口。 下面截图显示的是Visual Studio停在一个断点处 ,这段程序是用C ++代码创建的Android应用程序。在进程窗口,你可以看到的“调试”那一列显示“本机(GDB型)”,它表示这是VisualStudio针对Android的基于GDB的调试引擎. 在Visual Studio 2015 预览版中,值得注意的是C++的调试中有以下局限: 需要Android 4.2 及以上版本进行调试(Jelly Bean—API level 17) 停止调试并没有停止应用程序(它还在运行) 此外,不支持以下调试功能: 64位进程 更改异常设置在异常窗口 十六进制整数显示 断点绑定到多个位置(例如模板,具有完全相同的名称的文件) Android线程名字没有出现在线程窗口 在调用堆栈窗口显示参数值 附加到进程 自动窗口 返回值 使用JIT’d运行时间进行互操作调试(如Java或Xamarin) 只是我的代码 编辑并继续 任务窗口(包括并行堆栈窗口中的任务查看) 请尝试调试Visual Studio新的对C ++在Android上的调试支持,如果你发现任何上面并没有列出来的问题,请让我们知道。 最后,请让我们知道调试支持是如何为你工作的,并报告任何问题或整体反馈在下面,发送一个微笑功能, 通过VisualStudio或在我们的MSDN论坛。    

0

VS 2014 Preview 中的本地内存诊断

[原文发表地址]Native Memory Diagnostics in VS2015 Preview [原文发表时间]2014/11/21 7:19PM 在Visual Studio 2013 Update 2 和早期发布的VisualStudio 2015, CTP, 我们发布了一个内存诊断工具, 这个工具允许开发者截取应用程序的堆快照, 然后在终止它研究堆内容。在最初发布的版本中,支持查看堆管理和本地对象。并且在第一个Visual Studio2015 update CTP中增加了支持本机类型推导和值检验。 虽然这个工具是提供VisualStudio开发者含有一个收件箱内存分析器的一个良好开端, 但是在特定的程序状态下, 它缺乏一种轻松的分析堆内容的能力。因为为了更深层的研究数据,整个程序必须关闭。 改进的内存分析器进行预览 现在在Preview上,有一个新改进的内存分析器是可用的。它允许开发人员利用调试器强大的程序流程的控制力,并且在任何破发状态可以检验他们应用程序的堆内容。这是一个很好的对新的内存分析总结经验的一个概述。一个深入的特性总结完成了指令的激活功能。(我在那里找到它?章节),  在下面的这些指令是在第一次激活这个工具。 在调试期间,简单的按下F5将会启动新的分析器。现在为了查看堆快照不需要去终止程序。 这篇文章的剩余部分将集中介绍利用本机程序的新工具和详细介绍该工具的工作流程细节。 演示:分析 a Native MFC App 要展示新的内存分析器,一个被称为FamiTracker的MFC开源芯片定序器已经被加载到Visual Studio,并且为了建立新的编译器做了简单的修改。在启动内存分析器后,在应用程序中通过注册密钥和启动调试场景利用F5,工具加载。很快内存使用情况将被显示,并且下面的堆快照也将被显示:   快照可以在不同的点及时地的捕获堆状态,例如值仅可见于最近拍照时和处于破发状态时。 在这次练习中,对于FamiTracker,初始的程序状态是初始化序列UI:                                              FamiTracker 初始化编曲界面 另一个称为编辑器工具窗口会被打开为了编辑每一个编辑器的属性:                                           FamiTracker 编辑器窗口 利用新的内存分析器,为了更好的理解应用程序的内存消耗,我们将采取堆快照跨越两种程序状态。 首先,我们截取一个基本的快照为了储存初始化的堆内容: 工具编辑框被打开,这将在代码中触发一个断点,并且在程序状态中开始了一个变化,这个函数初始化工具编辑对话框和激活其它的一些辅助功能, 这将有助于创建工具编辑器的UI。 在OnInitDialog()开始断点的位置开始截取快照, 我们看到应用程序的堆内容之前,工具编辑器对话框启动分配对象。快照将列出对象类型,数量和内存占用。 由于我们在休息状态下, 通过双击某一行或者图标: 选择一个类型可以看到针对每一个实例的所有类型的分配情况,完整值和分配的调用堆栈。下面是所有CCHannelHandlerN163[]的实例:  …

0

Visual Studio 2013 Update 4 CTP1-GPU 使用率工具

[原文发表地址] GPU Usage tool in Visual Studio 2013 Update 4 CTP1 [原文发表时间] 2014/9/4 在发布了对Visual Studio 2013 Update 3 RC中图形诊断的一系列改进后,我们团队正致力于带给您更多的DirectX 应用的性能分析工具。在昨天发布的Visual Studio 2013 Update 4 CTP1(这里下载)中,您将在性能和诊断中心看到一个崭新的GPU使用率工具,您可以用它来收集和分析DirectX应用的GPU使用率的数据。CTP1支持本地运行Windows 桌面应用程序和Windows 应用商店应用。在后续的发布中,我们将会把对Window Phone 应用和远程分析的支持加入其中。您可以在这里找到相关文档,通过Channel9视频观看实时演示,或者通过此篇博客的余下内容获得更多有关此功能的信息。 如果所有的游戏以60FPS运行且没有任何性能问题可调查,那这个世界就太棒了!但是事实上,在开发和发布过后的时间里,一些应用程序往往不能达到它们的目标帧率-不论是PC上的60FPS还是小型数据终端的30FPS,或者那些应用程序的帧率在会话中期大幅度降低。 从:当多核可被使用时却仅利用了单核CPU,到:GPU渲染一个过于复杂的点阵,造成DirectX应用性能问题的原因变化多端。通常从剥离主要问题到底是超过了还是未达到CPU或GPU使用率开始,会对找到原因有很大帮助。这个GPU 使用率工具可以帮助您判断CPU或GPU是否是此应用的性能瓶颈。您也可以调查每一个GPU事件的时间,前提是在当前安装的是支持的显卡和最新的驱动。请查看此文档中支持的显卡列表,并登陆您的显卡供应商网站(Intel, NVidia, AMD)下载最新的驱动为此项功能提供GPU事件数据。 让我们开始第一次尝试吧! GPU 使用情况工具可以通过性能和诊断中心来加载,菜单:调试->性能和诊断或Alt+F2. 从这里您可以选择仅勾选GPU使用率或勾选包含其在内的其他工具,例如CPU使用率。 点击开始,将开始在用DirectX工程模板新建的默认DirectX工程上单独运行GPU使用率。在显示的用户账号控制对话框点击Yes,给收集数据赋予权限。 GPU使用率工具开始收集数据,并在打开的诊断会话文件中显示三部分图片,这些图片反应的实时数据不但包括在图形诊断工具中同样可见的帧时间和FPS,还包括一个崭新的GPU使用率图片用以展示GPU繁忙程度。 现在让我们点击底部的结束收集链接或顶部的结束按钮生成报告。生成的报告显示了实时会话的上述三部分图片。如果您想要深入分析时间轴的一段特定区域,例如若一段帧率或GPU使用率突然下降,您可以在时间轴选择一段区域并点击底部的这里链接查看GPU使用率数据的细节。在这个实例中,这个应用在整个会话过程中运行流畅,因此我们可以选取任意一段来调查GPU细节信息。 GPU细节信息窗口将会单独于此会话窗口打开。上半部分是时间轴视图,展示了每一个CPU内核和GPU引擎随时间的使用情况,下半部分是一个事件列表,展示了发生在GPU上的图形事件列表。需要注意的是这个事件列表的数据需要图形驱动的支持,因此如果您的显卡不支持或者您未安装最新的驱动,事件列表是不可见的,在这种情形下所有的时间将显示为:unattributed。您可以查看此文档中支持的显卡列表,并登陆您的显卡供应商网站(Intel, NVidia, AMD)下载最新的驱动为此项功能提供GPU事件数据。 所有使用GPU的进程都将被捕获,且每一个进程将在时间轴视图中有一个不同的颜色。在这个实例中,黄色代表了性能分析的目标进程,也就是App5.exe。 当您点击或是在事件列表中进行导航,您将看到在CPU和GPU泳道上显示的弹出小控件,展示所选事件在GPU上的执行时间,以及与它相对应的CPU工作发生在CPU上的时间。泳道中的淡灰色垂直线标记了每个监视器的垂直同步信号Vsyncs。Vsyncs线可以用来作为理解是否某个Present调用丢失了Vsyncs的参考。在每两个Vsyncs之间必须有一个Present调用,确保这个应用稳定达到60FPS。 这个GPU详细视图提供了以下有用的信息: CPU和GPU在一个更细粒度层次上的繁忙程度 DirectX事件在CPU上被调用的时间和在GPU上被执行的时间 每一个事件在GPU和CPU上消耗的时间 是否因为Present调用丢失Vsyncs而导致目标帧率下降 此功能的好处对于这个实例而言并不明显,因为这个应用过于简单,且GPU和CPU都不繁忙。在下一个阶段,我们将要在一个更现实的应用中尝试看看这些数据是如何被使用的. 让我们开始分析一个更现实的应用 在这个实例中,我们将会用到一个的内部测试的应用程序,它叫CityDemo,是一个渲染模拟城市的3D场景。这一次我们将要试着在同一个会话里面运行GPU使用率和CPU使用率两个工具。如果说要判断一个应用是CPU受限还是GPU受限仅用一个GPU使用率工具是必需的话,那么加入CPU使用率信息将会帮助我们更快地分析这种情况下是否CPU是问题的根源。 让我们再次加载性能和诊断中心,但这次我们选择GPU使用率和CPU使用率两个工具。FPS图告诉我们这个应用以40FPS运行。在FPS图中的红线代表默认的阀值:60FPS。如果您的目标是更低的帧率,可以使用下拉菜单降低到30FPS。而且您将注意到会显示一个CPU使用率图因为我们选择了CPU使用率工具。这个提供了一个GPU和CPU状态紧密结合的视图。在这种情况下,CPU利用率差不多20%,GPU使用率大约60%。那么CPU和GPU都没有满负荷,但是为什么这个应用程序没有达到60FPS? 为了解开这个疑惑,让我们深入GPU详细信息去看看,关于为什么这个应用运行缓慢是否能得到任何线索。因为这个图片是不变的,所以我们可以选择一段区域并打开GPU详细信息视图。从详细信息视图中的时间轴我们可以得到:…

0