CMake支持Visual Studio – 代码分析和CMake 3.11

[原文发表地址] CMake Support in Visual Studio – Code Analysis and CMake 3.11 [原文发表时间] 2018/05/02 Visual Studio 15.7预览版本4现已发布,除了预览版3中添加的目标视图和单个文件编译 功能外,这次我们添加了其它的CMake功能。我们尽可能保持Visual Studio中兼容的CMake版本是最新的,所以我们已将CMake版本更新至3.11。我们也很兴奋地宣布CMake项目现在支持以前需要利用VCXProj的IDE代码分析功能。 请下载预览版本并查看最新的CMake功能,例如目标视图,单个文件编译以及何时配置项目的更多控制。与往常一样,我们很乐意听到你的反馈。 如果你刚开始接触Visual Studio兼容的CMake功能,请查看博客如何开始。 CMake项目的代码分析 在最新的预览版本中,你现在可以在CMake项目上运行Visual Studio的全面代码分析工具。目前,你可以在目标级别运行代码分析。运行单个文件或者整个项目的代码分析选项即将推出 要在CMake目标上运行代码分析,你可以从CMake菜单中选择”运行代码分析”选项: 或者,如果你使用的是目标视图,只需要右键单击目标然后选择“运行代码分析”选项: 所有检测到的分析错误或警告都将显示在输出窗口中: 默认情况下,CMake项目使用”微软本机推荐规则”规则集,但可以通过修改CMakeSettings.json文件来更改该规则。只需将”CodeAnalysisRuleset”标记添加到配置中,并使用规则集文件的名称或路径即可。 CMake 3.11 为确保你的项目可以利用最新且最好的CMake功能,我们将Visual Studio中兼容的CMake版本从3.10升级到3.11。你可以在CMake 3.11发行说明中找到CMake 3.11的完整增强列表。 发送反馈 你的反馈是确保我们能够提供最佳CMake体验的关键部分。我们很想知道Visual Studio 2017 Preview如何为你工作。如果你有任何特定于CMake Tools的反馈,请联系cmake@microsoft.com。对于一般问题,请报告问题。 

0

C ++代码分析:命令行配置规则

[原文发表地址]:C++ code analysis: configure rules from the command line [原文发表时间]:2018年4月9日 [作者]:Sunny Chatterjee 和 Andrew Pardoe 这篇文章由Sunny Chatterjee和Andrew Pardoe撰写。 Visual Studio 15.7预览版3引入了一个新的MSVC编译器开关,/analyze:ruleset用于配置代码分析运行。 此开关的主要目的是用以支持使用C ++代码分析而不使用MSBuild过滤规则的开发人员。 但是,使用MSBuild进行代码分析的开发人员也从这种开关中受益:代码分析运行速度更快,从而提高了编译吞吐量。 什么是代码分析规则集? 代码分析规则集允许您选择在分析代码时看到的代码分析结果。 代码分析规则集可以在项目>属性>代码分析>常规 中找到。 默认情况下,新的C ++项目已选择规则集“Microsoft Native Recommended Rules” 您可以从突出显示的下拉列表中选择您希望应用于项目的规则集。 Visual Studio附带了一些您可以选择的内置规则集。 它们位于%VSINSTALLDIR%\ Team Tools \ Static Analysis Tools \ Rule Sets中。 我们正在增加这套规则 – 请继续关注VC博客,了解更多信息。 您也可以创建自己的自定义规则集并将其应用于您的项目。 要创建自定义规则集,请转至文件>新建>文件>常规>代码分析规则集。 在Visual Studio 2017 15.7版预览版3之前,每次运行C…

0

宣布C++单元测试的CodeLens

[原文发表地址] :Announcing CodeLens for C++ Unit Testing [原文发表时间] 2018/4/09          如果你刚开始使用C++单元测试,请访问我们的开始测试向导。          Visual Studio 的C++开发者现在可以尝试他们第一次的CodeLens!尤其是Visual Studio 2017 15.7 预览版 3的专业版和企业版都为单元测试提供了CodeLens. 这里有几种方式去初始化你的 CodeLens: 编辑并且生成你的测试的项目/解决方案 重新生成你的项目/解决方案 在测试 浏览窗口运行测试         执行上述任何操作之后,CodeLens 将会出现在你的单元测试中。CodeLens 允许你可以直接在源文件中去运行,调试并且可以访问你的单元测试的状态。测试状态指示器与测试资源管理器中的测试状态指示器相同:(警告:成功:失败:) 要更新测试状态,您可以直接从CodeLens上方运行测试,使其高于所需的测试方法。   如果您的测试失败了,又可以很容易的看到错误信息并且可以直接从CodeLens进行调试。 反馈         最后,如果您运行有任何的错误让我们知道,通过 点击帮助-> 发送反馈->报告问题去Visual Studio IDE。另外您可以在Developer Community访问已知的问题,添加评论和快速投票项目。您也可以在Twitter @nickuhlenhuth上找到我们。

0

C++核心检查在Visual Studio 2017 预览版 2

[原文发表地址] C++ Core Checks in Visual Studio 2017 15.7 Preview 2 [原文发表时间] 2018/3/22          C++ 核心准则检查扩展有了几个新的规则在 Visual Studio 2017 预览版2上。这次迭代主要在于检查,这将使从指南支持库中采用实用程序变得更加容易。         以下是对这些补充的简要总结。 有关更多详细信息,请参阅MSDN上的文档:C++核心指南检查器参考。         如果您刚开始使用本机代码分析工具,请参阅我们的介绍性快速入门:C / C ++代码分析。 新的规则集         在此版本中添加了一个新的规则类别,其中可以在项目设置对话框中选择规则集文件。 GSL规则          一些新的规则试图帮助捕捉有关如何使用跨度和视图类型的细微问题。 一旦现代的安全记忆处理实践得到采用,捕捉这些问题就变得更加重要。 此外,还会推出一些来自指南支持库的有用实用程序,以便使用户代码更安全,更均匀 新规则 界限规则 C26446 USE_GSL_AT         这个规则建议,只要没有执行范围检查的下标运算符被调用,就使用更安全的索引函数版本。        该规则也是GSL规则集的一部分。 函数规则 C26447 DONT_THROW_IN_NOEXCEPT        此检查适用于标记为“noexcept”的函数,并指向这些函数调用可能会抛出异常的代码的地方。 GSL规则 C26445 NO_SPAN_REF         当遗留代码迁移到指向内存缓冲区的新类型时,可能会发生一些细微问题。其中一个问题是,如果遗留代码用于引用容器(如矢量或字符串等),则可能会发生跨度或视图的意外引用。 C26448 USE_GSL_FINALLY…

0

在Visual Studio中的CMake支持 – 目标视图,单个文件编译和缓存生成设置

[原文发表时间] 2018/4/9 [原文发表地址] CMake Support in Visual Studio – Targets View, Single File Compilation, and Cache Generation Settings Visual Studio 2017 15.7预览版本3现已发布,其中包括对CMake工具的一些改进。最新的预览版本在如何显示,构建和管理CMake项目上比以往更加好控制。 请下载预览版本并查看最新的CMake功能,例如目标视图,单个文件编译以及对项目配置的更多控制。与往常一样,我们很乐意听到你的反馈。 如果你是Visual Studio中兼容的CMake的初使用者,请查看如何开始。 CMake目标视图 Visual Studio的最新预览版本提供了一个新方法来查看你的CMake项目源和结构。当你在Visual Studio中打开一个CMake项目时,你会在解决方案资源管理器中看到项目的磁盘布局。根据你的项目组织方式,这个基于磁盘的视图可能不能很好地反映你的CMake项目的实际结构情况。如果你的项目包含文件夹之外的文件,或者根据活动配置有条件地包含文件,则基于磁盘的视图尤其不利于观察。 新添加的目标视图允许你在解决方案资源管理器中可视化CMake项目的结构。在这个视图中,源代码是在单个CMake目标和项目下被组织的。你可以通过在解决方案资源管理器中通过右键单击来构建和调试单个目标。你还可以在参考节点下看到目标之间的联系和依赖关系。你还可以有更多的选项来自定义目标和源代码的显示结构—-请参阅下面的组织目标和源代码。 你可以通过单击解决方案资源管理器中的视图下拉菜单来显示目标视图: 如果你之前用过CMake生成的项目和解决方案,那么你应该感到很熟悉。这儿有一个顶级项目节点,CMake的Visual Studio生成器将生成一个解决方案,并且每个CMake目标都会和它的源代码下显示在此项目下。CMake生成器将为每个目标创建单独的MSBuild项目。但有一点需要记住,尽管视图很相似,但没有创建MSBuild项目或解决方案。该视图直接由CMake文件的内容驱动。 组织目标和代码源 你还可以控制目标和源代码的组织。可以通过启用use_folders并设置目标的文件夹属性来组织目标。源代码可以通过使用source_groups在目标下进行组织。这些指令适用于所有CMake IDE生成器(包括Visual Studio生成器),因此如果你已经设置了它们,它们就可以使用目标视图。 目标视图显示了CMake项目结构的表示。目前,你无法从目标视图中操作此结构。要修改项目的结构,你需要手动修改项目的CMake列表文件。 CMake项目的单个文件编辑 你现在可以像创建MSBuild项目一样构建属于CMake项目的单个文件。右键单击解决方案资源管理器中的任何源文件,然后选择“编译”或通过主CMake菜单来编辑在编辑器中打开的源文件: CMake缓存生成设置 默认情况下,当你第一次打开一个CMake项目时,Visual Studio会自动为你的CMake项目选择配置并生成缓存。 这使得IDE可以提供丰富的编辑,构建和调试体验,通常不需要额外的配置。但是,我们知道这中设置并不是对所有项目都是方便的,所以我们现在提供新的设置来控制CMake项目缓存的生成: 我们建议使用默认设置,但如果你通常需要额外配置的项目,或者想要更多地控制Visual Studio生成CMake项目缓存的方式和时间,则可能需要更改此设置。如果禁用自动生成缓存,Visual Studio会提醒你在编辑属于CMake项目的代码之前生成: 发送反馈 你的反馈是确保我们能够提供最佳CMake体验的关键部分。我们很想知道Visual Studio 2017 Preview如何为你工作。如果你有任何特定于CMake Tools的反馈,请联系cmake@microsoft.com。对于一般问题,请报告问题。

0

Visual Studio Code C/C++ 扩展2018年3月更新

[原文发表地址] Visual Studio Code C/C++ extension March 2018 update [原文发表时间] 2018/3/29 今天,我们很高兴地宣布2018年3月的Visual Studio Code C/C++ 扩展更新了!此次更新包括改进了本地和全局范围的自动完成功能,包括对系统includes和defines的配置过程的简化,都为了实现更好的智能感知体验。你可以在发行说明中找到完整的更改列表。 我们要感谢所有使用我们本月的内部构建并向我们发送反馈的人!我们修复了你们所报告的问题并改进了你们向我们提出的一些功能建议,这些帮助我们塑造了今天这个发布版本。如果你还不是内部人员,但有兴趣,我们很乐意你加入VS Code C/C++内部计划。   本地和全局范围的自动完成功能 尽管此功能并非是一个全新的功能,但当你输入本地和全局变量或是函数时智能感知提供了自动完成建议的语义感知列表。与以前的方法相比,新的自动完成体验为你提供了更短的和更相关的建议列表,使编写C/C++代码变得更加容易。 从编译器自动检索系统includes和defines 智能感知现在从基于GCC / Clang的编译器中自动检索系统includes和defines,从而无需在“includePath”和“定义”设置中进行手动配置。 在Mac和Linux上,智能感知引擎通过在系统上搜索已安装的编译器来自动选择编译器作为默认编译器。 你可以在c_cpp_properties.json文件中新加的“compilerPath”设置来检查正在使用哪个编译器,并可以根据需要更改该设置的值。“compilerPath”设置也接受影响系统定义返回的编译器参数。 另外,新加的“cStandard”和“cppStandard”两个设置允许为智能感知设置明确的语言标准。 强制智能感知处理任意的头文件 如果你希望智能感知可以处理那些未明确在#include语句列出的头文件,现在可以使用新加的设置“forcedInclude”来指定此功能。 智能感知引擎在查看#includes之前将首先处理这些头文件。 告诉我们你的想法 下载Visual Studio Code的C / C ++扩展,试用它,让我们知道你的想法。在GitHub上提出问题和建议。如果你尚未向我们提供反馈意见,请参阅此快速调查以帮助你制定符合你需求的扩展程序。你也可以在Twitter上找到我们(@VisualC)。

0

在Visual Studio中调试嵌入式ARM设备

  [原文发表地址]Debugging an embedded ARM device in Visual Studio [原文作者] Marc Goodner-MSFT [原文发表时间] 2018/1/10 我们在15.5版本的Visual Studio 2017中引入了对ARM GCC交叉编译的支持。在15.6 Preview 2中,我们添加了对调试的支持。这个调试功能的概述源自ARM交叉编译入门的安装,并将作为补充进行集成。 首先,确保输出具有调试符号很重要。在从ARM在线编译器导出的GCC项目中,他们不这样做。要添加它们,请在tools和flags部分下编辑makefile,并为GCC和G ++命令添加-g标志,如下所示。           CC      = ‘arm-none-eabi-gcc’ ‘-g’ …           CPP     = ‘arm-none-eabi-g++’ ‘-g’ … 现在,在构建二进制文件并刷新设备后,右键单击二进制输出,然后选择“调试”和“启动设置”。   在弹出的对话框中选择C / C ++调试微控制器(gdbserver)。   这将创建一个launch.vs.json,其中包含许多与嵌入式调试相关的选项.有很多方法可以调试这些设备,所以您在这里填写的内容将特定于您的开发板,硬件调试器及其提供gdbserver接口的相关软件。我们提供尽可能多的默认和提示,我们可以帮助你。在这个预览中,一些发出的环境变量还没有工作,你需要用所需的值替换它们。 $ {workspaceRootFolderName},您的文件夹名称 $ {env.gccpath},您的VS安装路径跟在Linux \ gcc_arm \ bin之后 $ {debugInfo.linuxNatvisPath},如果你有一个Natvis文件的路径。这是很好的删除,因为它是针对特定的情况 我将通过使用OpenOCD对ST Nucleo-F411RE进行配置。这个过程与大多数电路板相似。 首先,在输出中更改程序名称以指向您的.elf文件。…

0

Linux项目系统,Linux控制台窗口,同步和附加到进程的Linux C ++工作负载改进

[原文发表地址] Linux C++ Workload improvements to the Project System, Linux Console Window, 同步 and Attach to Process [原文发表时间] 2018/03/13 在Visual Studio 2017 15.7 Preview 1 中,基于你们的反馈我们对Linux C++ 工作负载的支持进行了一些改进。你可以在这里了解更多关于我们在Visual Studio中的Linux C++工作负载。 MSBuild 项目系统改进 我们在C/C++的常规属性页面上为Linux项目添加了一些新属性。最大的并行编译作业允许你启动其他编译过程。默认值是1,但可以增加以提高构建吞吐量。公共项目包含目录允许你指定要在解决方案中暴露给其他项目的项目中的目录。在消费项目中,添加对公开其包含目录的项目的引用,现在可以从源中引用它们。 Linux 控制台窗口改进 现在运行或者调试Linux项目时,将显示Linux控制台窗口。如果你停靠在这个窗口,这个位置将会在随后的运行中被记住。当你从调试模式返回时,窗口将被关闭。我们还修复了开启/关闭回声的处理,以正确显示来自远程系统的消息。  CMake 和打开文件夹的同步改进 我们在打开文件夹和CMake场景中的同步支持也看到了一些改进。以前,即使你已取消启动它的任务,同步也会运行完成,这已得到修复。如果同步是由构建触发的,例如你取消构建,同步现在将取消执行。我们还进行了一些性能改进,并为root用户启用了同步。你现在也可以使用CMakeSettings.json中的rsyncCommandArgs选项将其他命令参数传递给同步。 附加到流程改进 你已经向我们反馈了关于需要对远程Linux调试的附加到流程方案进行更多控制的需求。我们通过Linux项目或打开文件夹的正常调试启动设置添加了许多控件,例如启用子进程调试,预附连命令等。要启用此位置,请使用名为Microsoft.MIEngine.Options的文件。 xml在你的解决方案或工作区的根目录中。这是一个简单的例子。 <?xml version=”1.0″ encoding=”utf-8″?> <SupplementalLaunchOptions>     <AttachOptions>       <AttachOptionsForConnection AdditionalSOLibSearchPath=”/home/user/solibs”>         <ServerOptions MIDebuggerPath=”C:\Program Files…

0

构建时间改进建议:关闭/MAP,使用PDB

[原文发表地址] https://blogs.msdn.microsoft.com/vcblog/2018/03/14/build-time-improvement-recommendation-turn-off-map-use-pdbs/ [原文作者] YongKang Zhu [MSFT] [原文发表时间] 3/14/2018 映射文件是一个纯文本文件,其中包含有关链接器生成的二进制文件中存在的某些名称和符号的信息。它还包含二进制文件中的所有段的详细信息(代码,数据等)以及每个符号定义在哪个OBJ / LIB中。Windows调试器(如windbg.exe)可以使用映射文件来帮助定位程序崩溃的位置。映射文件是一种古老的技术:使用MSVC工具集的现代版本,PDB(程序数据库)文件可以完成所有映射文件的工作。 生成一个映射文件需要很长时间。如果你不需要映射文件但却在构建时看到了链接器选项/MAP,你应该移除它加快构建速度。最近我们已经完成了加速生成映射文件的工作,但是生成映射文件仍是一个缓慢的过程。 如果你是少数需要映射文件的人之一(例如,为了快速检查感兴趣的函数集或数据是否按照预期的或正确的二进制顺序排列),请放心,我们不会移除它。但是,以下几点将说明为什么您应该关闭/ MAP并使用PDB: 关闭映射文件生成可以缩短构建时间。虽然我们最近在完全链接场景中提高了映射文件生成的吞吐量,但链接器还是无法增量更新先前链接生成的映射文件,因为这会影响增量链接吞吐量。跟PDB文件不同的是,在增量链接期间可以通过链接器精准的更新PDB文件。 与PDB文件不同,二进制文件与其对应的映射文件之间没有紧密的绑定。跟踪哪个映射文件对应哪个版本的二进制文件是很困难的。 与PDB文件不同,符号服务器不支持映射文件。 PDB文件中的信息是映射文件中的内容的超集。实际上,几乎所有的版本都会默认生成PDB文件。 最后,我们已经发布 DIA API ,人们可以使用它来编写自己的工具来从PDB文件中检索当前在映射文件中可用的所有信息。 最后 我们知道构建的吞吐量对于开发人员非常重要,我们正在继续改进我们的工具集的吞吐量性能。你可以阅读我们最近发布的博客 Visual Studio 2017 吞吐量的改进和建议 来了解更多我们为提高吞吐量所做的事情。记住检查你的构建选项看看你是否在生成不必要的映射文件! 如果您对我们有任何意见或建议,请告诉我们。您可以通过在下方评论,通过电子邮件(visualcpp@microsoft.com )与我们联系,您也可以通过产品中的 帮助>报告问题 或通过 开发者社区提供反馈。您还可以在Twitter(@VisualC )和Facebook(msftvisualcpp )上找到我们。

0