msbuild

随着团队越来越多，越来越大，需求更迭越来越快，每天提交的代码变更由原先的2位数，暴涨到3位数，每天几百次代码Check In，补丁提交，大量的代码审查消耗了大量的资源投入。 如何确保提交代码的质量和提测产品的质量，这两个是非常大的挑战。 工欲善其事，必先利其器。在上述需求背景下，今年我们准备用工具和技术，全面把控并提升代码质量和产品提测质量。即： 1. 代码质量提升： 通过自定义代码扫描规则，将有问题的代码、不符合编码规则的代码扫描出来，禁止签入 2. 产品提测质量： 通过单元测试覆盖率和执行通过率，严控产品提交质量，覆盖率和通过率达不到标准，无法提交测试。 准备用2篇文章，和大家分享我们是如何提升代码质量和产品提测质量的。今天分享第一篇：通过Roslyn代码分析全面提升代码质量。 一、什么是Roslyn Roslyn 是微软开源的 .NET 编译平台(.NET Compiler Platform)。 编译平台支持 C# 和 Visual Basic 代码编译，并提供丰富的代码分析 API。 利用Roslyn可以生成代码分析器和代码修补程序，从而发现和更正编码错误。 分析器不仅理解代码的语法和结构，还能检测应更正的做法。 代码修补程序建议一处或多处修复，以修复分析器发现的编码错误。 我们写下面一堆代码，Roslyn编译器会有如下提示： 通过编写分析器和代码修补程序，主要服务以下场景

随着团队越来越多，越来越大，需求更迭越来越快，每天提交的代码变更由原先的2位数，暴涨到3位数，每天几百次代码Check In，补丁提交，大量的代码审查消耗了大量的资源投入。 如何确保提交代码的质量和提测产品的质量，这两个是非常大的挑战。 工欲善其事，必先利其器。在上述需求背景下，今年我们准备用工具和技术，全面把控并提升代码质量和产品提测质量。即： 1. 代码质量提升： 通过自定义代码扫描规则，将有问题的代码、不符合编码规则的代码扫描出来，禁止签入 2. 产品提测质量： 通过单元测试覆盖率和执行通过率，严控产品提交质量，覆盖率和通过率达不到标准，无法提交测试。 准备用2篇文章，和大家分享我们是如何提升代码质量和产品提测质量的。今天分享第一篇：通过Roslyn代码分析全面提升代码质量。 一、什么是Roslyn Roslyn 是微软开源的 .NET 编译平台(.NET Compiler Platform)。 编译平台支持 C# 和 Visual Basic 代码编译，并提供丰富的代码分析 API。 利用Roslyn可以生成代码分析器和代码修补程序，从而发现和更正编码错误。 分析器不仅理解代码的语法和结构，还能检测应更正的做法。 代码修补程序建议一处或多处修复，以修复分析器发现的编码错误。 我们写下面一堆代码，Roslyn编译器会有如下提示： 通过编写分析器和代码修补程序，主要服务以下场景

系列目录 Sonarqube下载与安装 Sonarqube下载地址是: https://www.sonarqube.org/downloads/ 下载版本有两个,一个是长期支持版,另一个是最新版,此处安装的是最新版,目前版本是7.3,下载的时候点击醒目的蓝色按钮即可(此时下载的是社区版),下面有三个无底色按钮下载链接,分别对应的是开发者版,企业版和数据中心版,这些版本都不是免费版,需要获取Licence key方可使用.目前起步阶段,使用社区版就Ok了. 注意 Sonarqube是基于java语言开发的,因此运行之前必须先安装Jre Sonarqube支持Windows,mac和linux,但是安装包并不区分平台,也就是这三个平台下载包是一样的,只是启动方式不同. 下载完成全将下载的压缩包解压,进入bin目录,可以看到这个目录下有数个文件夹,从文件夹的名称很容易看出它们对应的是windows,mac,linux平台下的启动目录,由于我们是在windows平台下运行的,因此进入windows-x86-64目录(当然,如果你的电脑是32位系统,则进入windows-x86-32目录)此目录下面有很多脚本文件,我们双击 StartSonar.bat 这个批处理文件来运行windows下的sonarqube,启动需要数十秒时间,请耐心等等.当看到控制台最后一句是 SonarQube is

Mac上利用VScode配置c/c++开发环境 哭辽，Typora里面最好不要插入表情，不然保存会闪退 首先你要有一个vscode 在扩展里面下载c/c++ 第一步 ⬆+com+p 打开命令模式：选择c/c++： 编辑配置（edit configuration） 然后再自动生成的.vscode目录，打开c_cpp_properties.json。利用老哥的文件示例： { "configurations": [ { "name": "Mac", "includePath": [ "${workspaceFolder}/**", "/Library/Developer/CommandLineTools/usr/include/c++/v1", "/usr/local/include", "/Library/Developer/CommandLineTools/usr/lib/clang/11.0.0/include", "/Library/Developer/CommandLineTools/usr/include" ], "defines": [], "macFrameworkPath": [ "/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks", "/System

https://visualstudio.microsoft.com/zh-hans/thank-you-downloading-visual-studio/?sku=BuildTools&rel=16 https://visualstudio.microsoft.com/zh-hans/vs/older-downloads/isolated-shell/ https://visualstudio.microsoft.com/zh-hans/vs/older-downloads/ https://visualstudio.microsoft.com/zh-hans/visual-cpp-build-tools/?rr=https%3A%2F%2Fwww.baidu.com%2Flink%3Furl%3DPA6ECDy6C4Wd-jnXk3BxDdVGHzQMZUS4mF0LdioWvz2r0gFIJD319sXwf5Ockmjgsqia-ccCwb79t_M3vYgXujv4bIlqTbQGh2zh-yO3IZ_%26wd%3D%26eqid%3D94b3b9620003aa54000000055cce5bdd 开发环境： win10 + Microsoft Visual C++ Build Tools 2015 ----------------------------------

在 csproj 文件或在 NuGet 的 Targets 文件中可以通过 Target 调用 ZipDirectory 任务用来制作压缩包，在构建的时候，可以用这个方法将某个输出文件夹等内容压缩输出 使用 ZipDirectory 有两个必要的属性，一个是 DestinationFile 表示输出的 zip 文件的路径，另一个是 SourceDirectory 表示将被压缩的文件夹路径 如果 DestinationFile 文件期望进行覆盖，也就是如果 DestinationFile 路径已经存在，将覆盖写入新的 zip 文件，可以使用 Overwrite 属性 使用方法如下 <Target Name="ZipOutputPath" AfterTargets="Build"> <ZipDirectory SourceDirectory="$(OutputPath)" DestinationFile="$(MSBuildProjectDirectory)\lindexi.zip" /> </Target> 将上面代码放在 csproj 文件，构建将会在 csproj 文件所在文件夹找到创建的文件 本文代码放在 github 欢迎小伙伴访问 ZipDirectory Task 我搭建了自己的博客 https://blog.lindexi.com/ 欢迎大家访问，里面有很多新的博客

《西游记》中真假美猴王让人着实难以区分，但是我们熟知了其中的细节也不难把他们剥去表象分别出来。对问题不太关心的可以直接调到文中关于 .Net文件版本的介绍 问题 最近在编译AKKA.net 时出现了一个问题： Newtonsoft.Json.dll 冲突. C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3243: No way to resolve conflict between " Newtonsoft.Json, Version=7.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed " and " Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed ". Choosing "Newtonsoft.Json, Version=7.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" arbitrarily. Consider app.config remapping of assembly

前言 相信每一位程序员都经历过深夜加班上线的痛苦！而作为一个加班上线如家常便饭的码农，更是深感其痛。由于我们所做的系统业务复杂，系统庞大，设计到多个系统之间的合作，而核心系统更是采用分布式系统架构，由于当时对系统划分的不合理等等原因导致每次发版都会设计到多个系统的发布，小的版本三五个，大的版本十几个甚至几十个系统的同时发布！而我们也没有相应的基础设施的支撑，发版方式更是最传统的，开发人员将发布包发给运维人员，由其讲各个发布包一个一个覆盖到生产环境。因此每次上线仅仅发版就需要2-3个小时。这种方式不仅仅耗时、耗力，更是由于人工操作经常导致一些丢、落的现象。而我们当时的测试也是采用纯手工的测试，发版完毕后一轮回归测试就需要3-4个小时(当时主要是手工测试)。之前也一直提倡持续集成、自动化的测试和运维，但迟迟没有推进落地。终于在一个加班到凌晨四点的夜晚后，我再也受不了。回家后躺在床上迟迟睡不着，心想这个自动化的发布能有多难，他们搞不了，老子自己搞，于是6点爬起来来到公司，正式开始了我的持续集成、自动化部署的研究与推进之路。 一、初识Jenkins 由于之前亦没有相关知识的积累，因此也是对如何实现也是一头雾水。于是只能找度娘，关键字"自动化发布"。搜索到很多工具和方法，但都是以Java平台居多，.net平台相关资料不多。其中以Jenkins介绍较多，微软也提供一套自动化部署的方式

文章导航-readme .NET持续集成与自动化部署之路第一篇(半天搭建你的Jenkins持续集成与自动化部署系统) 前言 相信每一位程序员都经历过深夜加班上线的痛苦！而作为一个加班上线如家常便饭的码农，更是深感其痛。由于我们所做的系统业务复杂，系统庞大，设计到多个系统之间的合作，而核心系统更是采用分布式系统架构，由于当时对系统划分的不合理等等原因导致每次发版都会设计到多个系统的发布，小的版本三五个，大的版本十几个甚至几十个系统的同时发布！而我们也没有相应的基础设施的支撑，发版方式更是最传统的，开发人员将发布包发给运维人员，由其讲各个发布包一个一个覆盖到生产环境。因此每次上线仅仅发版就需要2-3个小时。这种方式不仅仅耗时、耗力，更是由于人工操作经常导致一些丢、落的现象。而我们当时的测试也是采用纯手工的测试，发版完毕后一轮回归测试就需要3-4个小时(当时主要是手工测试)。之前也一直提倡持续集成、自动化的测试和运维，但迟迟没有推进落地。终于在一个加班到凌晨四点的夜晚后，我再也受不了。回家后躺在床上迟迟睡不着，心想这个自动化的发布能有多难，他们搞不了，老子自己搞，于是6点爬起来来到公司，正式开始了我的持续集成、自动化部署的研究与推进之路。 系列文章 .NET实现持续集成与自动化部署1-Jenkins .NET实现持续集成与自动化部署2-NuGet .NET实现持续集成与自动化部署3

.NET持续集成与自动化部署之路第一篇(半天搭建你的Jenkins持续集成与自动化部署系统) # 前言 # 相信每一位程序员都经历过深夜加班上线的痛苦！而作为一个加班上线如家常便饭的码农，更是深感其痛。由于我们所做的系统业务复杂，系统庞大，设计到多个系统之间的合作，而核心系统更是采用分布式系统架构，由于当时对系统划分的不合理等等原因导致每次发版都会设计到多个系统的发布，小的版本三五个，大的版本十几个甚至几十个系统的同时发布！而我们也没有相应的基础设施的支撑，发版方式更是最传统的，开发人员将发布包发给运维人员，由其讲各个发布包一个一个覆盖到生产环境。因此每次上线仅仅发版就需要2-3个小时。这种方式不仅仅耗时、耗力，更是由于人工操作经常导致一些丢、落的现象。而我们当时的测试也是采用纯手工的测试，发版完毕后一轮回归测试就需要3-4个小时(当时主要是手工测试)。之前也一直提倡持续集成、自动化的测试和运维，但迟迟没有推进落地。终于在一个加班到凌晨四点的夜晚后，我再也受不了。回家后躺在床上迟迟睡不着，心想这个自动化的发布能有多难，他们搞不了，老子自己搞，于是6点爬起来来到公司，正式开始了我的持续集成、自动化部署的研究与推进之路。 一、初识Jenkins # 由于之前亦没有相关知识的积累，因此也是对如何实现也是一头雾水。于是只能找度娘，关键字"自动化发布"。搜索到很多工具和方法