.Net

一：背景1. 讲故事上个月有位敌人通过博客园的短消息找到我，说他的程序存在内存溢出状况，寻求如何解决。 要解决还得通过 windbg 剖析啦。 二：Windbg 剖析1. 为什么会内存溢出大家都晓得内存溢出对应着 .NET 中的 OutOfMemoryException 异样，这种异样有可能是托管代码手工抛出的，也有可能是CLR层面抛出的，话中有话就是能够通过两种形式排查。 托管线程是否挂载着异样？0:000> !tThreadCount: 23UnstartedThread: 0BackgroundThread: 5PendingThread: 0DeadThread: 17Hosted Runtime: no Lock ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception 0 1 362c 00fac868 26020 Preemptive 7ED701A0:00000000 00fa6b60 0 STA 5 2 2d70 00fbeba0 2b220 Preemptive 7EBA7AC0:00000000 00fa6b60 0 MTA (Finalizer) 7 3 3264 061c8890 102a220 Preemptive 00000000:00000000 00fa6b60 0 MTA (Threadpool Worker) 17 15 3f98 19682b90 202b220 Preemptive 7EBB0830:00000000 00fa6b60 0 MTA XXXX 16 0 2845fb00 35820 Preemptive 00000000:00000000 00fa6b60 0 Ukn 18 14 a7c 2842b1c8 202b220 Preemptive 00000000:00000000 00fa6b60 0 MTA XXXX 6 0 2c9b3778 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) XXXX 18 0 288a1318 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) XXXX 23 0 288a22f0 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) XXXX 10 0 2ccf3550 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) XXXX 21 0 288a1860 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) XXXX 12 0 288a1da8 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) XXXX 11 0 2c993640 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) XXXX 8 0 2ccf3a98 35820 Preemptive 00000000:00000000 00fa6b60 0 Ukn XXXX 9 0 2ccf2030 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) XXXX 7 0 2c9aed88 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) XXXX 26 0 28898308 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) XXXX 25 0 2c492c68 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) XXXX 4 0 2c993b88 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) XXXX 20 0 2c9af2d0 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) XXXX 17 0 2c9afd60 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) XXXX 24 0 2c9b1280 1039820 Preemptive 00000000:00000000 00fa6b60 0 Ukn (Threadpool Worker) 23 22 2658 2c9b02a8 1029220 Preemptive 7ED5BFF8:00000000 00fa6b60 0 MTA (Threadpool Worker) 从输入信息看，这些线程并没有挂载任何托管异样，我去。。。 ...

流动介绍微软技术直通车第九期，将于2021年12月12日面向大家，本次流动受疫情影响，将转移到线上举办，期待您的退出和参加。本期邀请了国内南北微软技术专家强强联合，与大家一起实际和体验2021 .Net Conf & Ignite Post Watching Party 北京专场流动，将分享微软 .Net Conf 2021大会和微软寰球 Ignite 2021大会的盛况，以及专家的独到见解，联合相干行业的发展前景和从业教训，交换如何进步微软相干技术给大家带来的潜在价值。 流动工夫：2021年12月12日 14:00-17:00参加形式：报名后，在“上课形式”中获取 扫码报名参加 嘉宾介绍 10年以上互联网利用架构教训，在R、Java、NodeJS、大数据、数据挖掘等方面有深厚的积攒。精通量化投资交易策略，相熟中国金融二级市场、交易规则和投研体系。相熟数据学科方法论，在外汇、海关、区块链等畛域均有落地的利用。著有《R的极客现实：量化投资篇》、《R的极客现实：工具篇》、《R的极客现实：高级开发篇》，英文版图书被CRC出版团体引进，在美国发行。 集体博客：http://fens.me 分享主题：用R语言进行量化文本剖析：像结构化数据一样治理文本 在互联网的明天，咱们每天都会生产和生产大量的文本信息，如报告、文档、新闻、聊天、图书、小说、语音转化的文字等。海量的文本信息，不仅提供扩宽的钻研对象和钻研畛域，也为商业应用带来了微小的机会。 量化文本剖析（Quantitative Analysis of Textual Data），一种新的形式，用结构化数据的形式来治理文本。quanteda包，提出以语料库的模式治理文本，语料库被定义为文本的汇合，其中包含特定每个文本的文档级变量，和整个汇合的元数据。用户能够轻松地按单词、段落、句子甚至用户提供的分隔符宰割文本和标签，按文档级变量将它们分组为更大的文档，造成基于逻辑条件的变量组合。 10年微软最有价值专家，多年耕耘在开发前沿，《ASP.NET 本质论》作者，《精通 ASP.NET Core MVC》译者。 分享主题：在 .NET 6 中利用 OpenTelemetry 可察看性是微服务化利用的几个外围个性，OpenTelemetry 连续了 OpenTracing 和 OpenCensus 的倒退，成为 CNCF 的针对可察看性的新规范。 该分享将首先介绍 OpenTelemetry 的外围概念，微软作为 OpenTelemetry 的核心成员，.NET 平台对于 OpenTelemetry 提供了优异的反对，这里将基于 .NET 6 介绍如何利用 OpenTelemetry 到 .NET 我的项目中。 领有超过14年的技术研发和治理教训，在数据挖掘和人工智能畛域有十分丰盛的积攒。间断6年（2017-2022）被微软评为最具价值专家（MVP），中国现场统计研究会大数据统计分会首届理事。 分享主题：Keras深度学习：入门、实战及进阶 Keras是一个对小白用户十分敌对而简略的深度学习框架，它是TensorFlow高级集成API，其特点是可能疾速实现模型的搭建，是高效地进行科学研究的要害。本主题将介绍如何进行图像及文本数据预处理，并介绍深度学习罕用的DNN、CNN、RNN、GAN等模型原理及Keras案例实现。 14:00 收场 14:05 MVP 我的项目介绍 14:15 用R语言进行量化文本剖析：像结构化数据一样治理文本张丹R语言实践者；北京青萌数海科技有限公司CTO；微软MVP15:05 劳动15:10 Keras 深度学习：入门、实际及进阶谢佳标资深AI技术专家和数据挖掘专家；微软MVP16:00 劳动 16:05 在 .NET 6 中应OpenTelemetry 郝冠军10年微软最有价值专家主办方 ...

原文：https://docs.microsoft.com/en...本文对原文进行了提炼并翻译为中文。 Cancel不代表终止代码不要想当然地依附Cancel机制“terminate a Task”，这是做不到的！ 一个常见的误会是勾销了一个工作后，该工作就会主动进行；但其实这种了解是不正确的；试想一下，如果勾销真的能够达到terminate一个Task的成果，那它和危险的Thread.Abort有什么区别呢？因为真的依照“cancel即在Task代码外部抛出异样”去了解，那么你没有对完结后的程序状态有任何开头工作。 所以CancellationTokenSource抑或其对应的CancellationToken都只是发一个告诉给Task：你能够完结了；而具体怎么捕捉这个音讯并响应，是Task的用户代码本人思考的问题。 参考原文中的代码，要害的一个片段是： if (ct.IsCancellationRequested){ Console.WriteLine("Task {0} cancelled", taskNum); ct.ThrowIfCancellationRequested();}这相似于软件工程中的“埋点”，即在要害的代码行中插入监控代码，判断工作是否被勾销 WhenAny或Wait(token)会导致异样抛出看回原文中的代码： try{ await Task.WhenAll(tasks.ToArray());}catch (OperationCanceledException){ Console.WriteLine($"\n{nameof(OperationCanceledException)} thrown\n");}一旦工作勾销，那么Task.WhenAll会导致异样抛出；这里是非常容易误导人的一点：Task外部也产生了异样，从而打断的Task外部代码流，从而令工作强制退出了吗？ 答案是：Task自身代码运行只受到本人外部代码管制，不可能单单因为CancellationTokenSource收回了勾销信号，就终端了工作的运行。

ML.NET 是面向 .NET 开发人员的开源跨平台机器学习框架，你能够应用 C# 或 F# 创立自定义 ML 模型，而无需来到.NET 生态系统。ML.NET 使你可能在联机或脱机场景中将机器学习增加到 .NET 应用程序中。借助此性能，机器学习应用程序利用数据中的模式来进行预测，而不须要进行显式编程。 ML.NET 的外围是机器学习模型，该模型指定将输出数据转换为预测所需的步骤。借助 ML.NET，能够通过指定算法来训练自定义模型，也能够导入预训练的 TensorFlow 和 ONNX 模型。领有模型后，能够将其增加到应用程序中进行预测。能够应用 ML.NET 进行的预测类型的示例： ML.NET 在应用 .NET Core 的 Windows、Linux 和 macOS 或应用 .NET Framework 的 Windows 上运行。所有平台均反对 64 位。Windows 反对 32 位，TensorFlow、LightGBM 和 ONNX 相干性能除外。 简略介绍了什么是ML.NET之后，咱们为你筹备了Let’s Learn .NET系列栏目之机器学习篇，帮忙你更加直观地理解，以及文末也附上收费的学习素材，内容丰盛，能够先珍藏再学习哦！ 扫描二维码观看视频 欢送关注微软中国MSDN订阅号，获取更多最新公布！

一：背景1. 讲故事上个月有位敌人找到我，说他的程序呈现了内存透露，不晓得如何进一步剖析，截图如下： 敌人这段话曾经说的十分长篇累牍了，那就上 windbg 谈话吧。 二：Windbg 剖析1. 到底是哪一方面的透露依据敌人形容，程序运行一段时间后，内存就炸了，应该没造成人员伤亡，不然也不会跟我wx聊天了，这里能够用 .time 看看以后的 process 跑了多久。 0:000> .timeDebug session time: Thu Oct 21 14:54:39.000 2021 (UTC + 8:00)System Uptime: 6 days 4:37:27.851Process Uptime: 0 days 0:40:14.000 Kernel time: 0 days 0:01:55.000 User time: 0 days 0:07:33.000看的进去，这个 dump 是在程序跑了 40min 之后抓的，接下来咱们比拟一下 process 的内存和 gc堆 占比, 看看到底是哪一块的透露。 0:000> !address -summary--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_FREE 327 7dfc`c665a000 ( 125.987 TB) 98.43%MEM_RESERVE 481 201`e91a2000 ( 2.007 TB) 99.74% 1.57%MEM_COMMIT 2307 1`507f4000 ( 5.258 GB) 0.26% 0.00%0:000> !eeheap -gcNumber of GC Heaps: 2------------------------------GC Allocated Heap Size: Size: 0x139923528 (5260850472) bytes.GC Committed Heap Size: Size: 0x13bf23000 (5300695040) bytes.从卦中可轻松得悉, 这是一个完完全全的托管堆内存透露。 ...

设想一下，假如你是一家披萨公司的开发者，领导要求你开发一个披萨库存治理页面，同时该页面也要与公司外部治理网站买通。应该如何疾速且精确地实现这样一个工作呢？ 花上不到1个小时的工夫，跟着咱们一起学习《应用 ASP.NET Core 创立 Web UI》，就可轻松实现本次工作！在本次课程中，咱们将应用 .NET Core CLI 和 Visual Studio Code（Windows、Linux 和 macOS）来演示 ASP.NET Core Razor Pages 开发。 学习实现后，你将可能理解在 ASP.NET Core 利用中应用 Razor Pages 的机会和起因应用 .NET Core CLI 在利用中创立新的页面创立一个反对利用的产品数据管理要求的窗体应用 Razor 的输出标记帮忙程序增加客户端窗体输出验证应用数据正文增加服务器端模型验证运行并测试 Web 利用

.NET 多平台应用程序 UI (.NET MAUI) 能够应用单个代码库为 Windows、macOS、iOS 和 Android 构建本机客户端应用程序，并为 Blazor 混合计划提供本机容器和控件。.NET MAUI 是 Visual Studio 中的一个框架，它形象了曾经可用的本机 UI 框架——WinUI for Windows、Mac Catalyst for macOS/iPadOS、iOS 和 Android。只管它不是另一个本机 UI 框架，但仍有大量工作须要在这些设施上提供最佳开发和运行时体验。 .NET 团队始终在与社区一起致力的开发，咱们致力于它的公布。可怜的是，.NET MAUI 将无奈在 11 月与 .NET 6 GA 一起公布。咱们心愿在第一天就为咱们的用户提供最佳体验、性能和品质，为此，咱们须要推延时间表。咱们当初的指标是在 2022 年第二季度初推出 .NET MAUI 。 与此同时，咱们将持续加强 Xamarin 并举荐它用于构建生产挪动应用程序，并持续公布 .NET MAUI 的月度预览。咱们打算为 .NET MAUI 提供的所有性能将在 11 月 .NET 6 公布时提供，但咱们将持续努力提高品质并解决客户反馈。咱们激励您尝试预览。.NET 降级助手还将反对将 Xamarin 我的项目降级到 .NET MAUI。 .NET 6 RC1 是最终版本之前的版本，这意味着您能够在生产中应用它并取得反对。这不包含 .NET MAUI 包。.NET MAUI 包的下一个版本，当 .NET 6 RC2 公布时，将在版本中显示“预览”。 ...

最近，咱们推出了.NET MAUI Community Toolkit，并且当初已做好了承受社区奉献的筹备。 咱们批改了增加新性能的工作流程，在此分享给各位，以不便大家今后持续欠缺，做出奉献。 咱们还为此创立了一个我的项目看板，以便您在这里跟踪新的工作流程： 新性能工作流程新性能工作流程在很大水平上受到了C#团队当前工作流程的启发，可能优化其Discussions and Proposals的施行。 展开讨论所有的新性能都将以探讨的模式开始。 作为一个社区，咱们能够在此探讨新性能的长处和毛病，确定它的范畴，它的API外表的状态，并就其施行达成共识。 开启新性能提案一旦某个新性能的施行在探讨中达成统一，就能够提交新性能提案了。 新性能提案是相当深刻的，须要以下信息： 摘要具体设计应用句法（XAML的用法和C#的用法）毛病代替计划未解决的问题提案负责人在呈现一个新提案后， .NET MAUI Community Toolkit 团队的一名成员将被选为负责人，意味着该团队成员批准将其纳入.NET MAUI Community Toolkit，他们将在下一次 .NET MAUI Community Toolkit 月度讨论会上对该提议进行投票。 在每个月的第一个星期四下午12点，咱们会在.NET基金会的YouTube频道上直播咱们的会议，除此之外，咱们会对新性能提案进行投票。如果某个提案失去外围团队50%以上的反对，它就被正式批准了。 批准提案一旦提案被批准，就终于到了开始写代码的时候了。 在该阶段，咱们将把提案调配给任何违心为之做出奉献的社区成员。 请在任何提案上留下评论，标记为须要帮忙，咱们会很快乐地把它调配给你。 咱们要求每个Pull Request在合并前包含以下我的项目： 施行iOS 反对Android 反对macOS 反对Windows 反对单元测试示例XML文档批准Pull Request在这一步，代码曾经实现，包含单元测试、XML文档和 .NET MAUI Toolkit 示例利用中蕴含的内容。 当初惟一妨碍该Pull Request被合并的是Microsoft文档GitHub库中的官网文档的实现状况。因为官网文档在不同的仓库中，咱们增加了待定文档标签，以确保咱们肯定会实现此文档。 咱们要求Pull Request的作者也参加编写该性能的官网文档，因为你是最理解该性能的人。当然，如果你的英语不好，咱们也很乐意帮你审阅编辑。 批准文档文档实现后，将由.NET MAUI Community Toolkit团队的成员进行审查、批准和合并。 文档实现后，就能够合并该Pull Request了。 实现终于实现了。 Pull Request已被合并，正式将你的代码增加到 .NET MAUI Community Toolkit中。 另外，咱们还为大家筹备了 .NET 6 和 Visual Studio 2022 的技术干货合集！全新的集成开发环境、多项改良以及配套资源上新，为开发者们带来生产力的晋升和工作品质的改善。 ...

Windbg程序调试是.NET高级开发须要把握的必备技能，剖析内存泄露、剖析CPU高使用率、剖析线程阻塞、剖析内存对象、剖析线程堆栈、Live Dedugging。这些Debug畛域能够说一个技能+场景化利用的联合，如果只依附Windbg几个简略的命令，不了解每个指令在理论Troubleshooting中的作用，是没有意义的。工欲善其事必先利其器，咱们先从罕用的命令和示例说起。 Windbg 常用命令先筹备一个Dump文件，倡议应用64位应用程序。例如：64位IIS利用的w3wp过程，64位exe过程都能够。如果抓Dump文件，很简略：工作管理器-过程-右键【创立转储文件】。 而后下载并装置Windbg，下载链接：https://developer.microsoft.c...，一路下一步，抉择【Debugging Tools for Windows】。 关上之后，Ctrl+D，关上第一步抓的Dump文件，开始明天的常用命令介绍。 加载SOS调试扩大dll。.loadby sos clr设置并从新加载调试符号文件的命令，将.Net 一些重要的pdb文件下载到指定的门路中，加载到Windbg调试环境中，这样，咱们就能够看到程序在哪一行出错，运行到哪一行了。.symfix+ C:\symbols.reload打印以后调试符号文件搜寻门路。0:000> .sympath查看线程池，剖析并确认CPU使用率，能够应用哪个指令。0:000> !threadpoolCPU utilization: 2%Worker Thread: Total: 19 Running: 2 Idle: 17 MaxLimit: 32767 MinLimit: 4Work Request in Queue: 0--------------------------------------Number of Timers: 2--------------------------------------Completion Port Thread:Total: 4 Free: 4 MaxFree: 8 CurrentLimit: 4 MaxLimit: 1000 MinLimit: 4查看线程的整体运行状况。!threads 查问指定线程的调用堆栈，例如34号线程。 ~34s !clrstack 查看线程耗费CPU资源状况。!runaway 第一列是线程号，第二列是Total的CPU应用工夫 查看以后线程栈上所有对象的信息，Dump stack objects。 查问内存中指定对象的信息 Dump object。!do查问内存中指定数组对象的信息 Dump Array。!de 查看以后线程的堆栈和每行堆栈上的变量信息。!clrstack -aWindbg 附加过程调试，启用CLR异样捕捉、查看异样、查看异样所在线程堆栈、禁用CLR异样调试、退出调试。sxe clrg!pe!clrstacksxd clrqd查看托管堆上内存对象的散布、三个代的信息。!eeheap -gc ...

大家好！我是爱吃、爱玩、更爱学习技术，IT届的新晋网红，开发者的好敌人—比特熊！ 比特熊真的太太太太想看《黑客帝国：矩阵重启》了！ 没想到，本期参加直播的苏震巍老师比本熊更资深，他甚至把本人的公司打造成了“黑客帝国风”！ 所有办公室、会议室的命名都出自《黑客帝国》：锡安城、尼布甲尼撒号、船坞、市中心，而且取这些名字都有起因，比方两艘旗舰Hammer号和尼布甲尼撒号就是两个十分像的会议室，船坞则是一个开放式办公区域。 锡安城是散会的中央，市中心则是财务和行政，“门始终关着，我都进不去。”苏老师在直播中吐槽，“‘源头’是咱们的机房，外面全是源代码。303是咱们的直播和新媒体，因为303是一个穿梭的门对不对？” （《黑客帝国》中303号房间用于进出“母体”） 比特熊：本熊太艳羡了！有机会肯定要参观下！ 【比特熊故事汇】作为比特熊直播间系列栏目的首发，将定期邀请技术大牛和行业先锋做客。这里不仅讲最“热”的技术，还有更多待解锁的集体故事和趣味话题！在这里打个广告，欢送酷爱技术分享、有故事的敌人来到比特熊的直播间！ 比特熊：喜迎.NET 6公布，本期直播间围绕.NET开展！这次的【比特熊故事汇】邀请到了三位微软MVP——杨中科、陈超超、苏震巍。大家一起聊聊.NET 6新个性以及为什么要用.NET 6，还有超多实例、精彩故事、电影分享、流动预报……切实是太丰盛了！ 比特熊：但大家可能留神到了，明天现场就一只熊，难道我没有请到嘉宾？ 当然不是啦，这次的三位老师都在线上参加，此前他们在微软Reactor和各种社区活动中大家都十分相熟了，置信通过明天的直播，大家和比特熊都会对老师们有更深刻的理解。 尽管比特熊与三位老师都还是网友关系，但通过线上交换曾经很相熟了。杨中科老师是比特熊眼中的视频分享高产小户，视频内容不仅有技术还有学英语等等，连B站给他的标注都是B站出名Up主。第一次晓得陈超超老师是在加入微软MVP线上会议的时候，超超老师不仅讲了本人的技术长项还慷慨举荐本人喜爱的游戏，让比特熊眼前一亮！比特熊还关注了超超老师在微软Reactor分享的 “进击吧！Blazor！”系列，在开发者圈子里很受欢迎，取得了超高的点击量！咱们title很长的苏震巍老师，不仅是Development Technology方向的MVP，还是咱们微软的RD。置信有不少搭档跟比特熊一样也常常在社区活动中见到过苏老师，也有幸听过他的分享。 比特熊：.NET 6公布之后，很多开发人都十分兴奋，在各种平台上分享本人的喜悦、观点和想法，上面是杨中科老师对这次公布新变动的划重点： 1、最值得关注的.NET 6特色——Source Generator，代码生成器存在于软件开发行业十分多年了，但微软是第一个把Source Generator做到编译器这个级别，十分值得期待。 2、Record。不可变的类在性能、并发、解决方面都十分好，C#里边Record这个类型会让咱们编写一个不可变类变得十分不便。 3、顶级语句。只写一句最重要的代码就能够让程序跑起来，升高C# 开发的门槛。 4、可空援用类型，缩小bug。 5、WebView2，混合式开发， 6、Hot Reload，一番折腾终于保留，进步开发效率。 比特熊：陈超超老师则从晋升效率、加重工作量的角度介绍了.NET 6： 1、这次C# 10减少了很多的性能，列举两个简略的：一个是咱们当初代码越写越长，屏幕空间其实是很贵重的。当初C# 10之后，用顶级命名空间就能够解决这个问题；第二个是扩大属性， 10.0之后能够采纳这种写法，让咱们的代码越来越语义化，越来越精简。 2、换一个角度看抉择.NET 6的理由。图中是目前市面上所有的框架当中，性能比拟全面的框架，就是包含前端后端都都反对的框架外面，ASP.NET排在第8名。为什么我说性能跟咱们的工作量无关？当你性能足够强的时候，会省下很多优化的工夫。.NET 6性能的改良——替换整体晋升将近翻倍，比照则晋升了将近一个数量级，意味着咱们对硬件资源的需要更少了。对咱们做制造业的人来说，IT部门是花钱的，老本升高就是变相的利润增长。 3、ASP.NET Core新个性：Minimal APIs 缩小控制器的无意义代码，让程序结构更简略；Balzor（两个人做的事件，当初只须要一个人做）新个性。 4、Dapr，缩小学习老本，团队完结语言之争，框架之争，公司实现所有开发资源在一个体系下工作。 5、DevExpress拥抱开源，但商业软件也有其价值。 比特熊：超超老师提到了开源，这一次苏震巍老师也分享了他们的明星我的项目从 .NET 3.5 到 .NET 6.0 的开源迭代之路，以及.NET 6.0 新个性对开源我的项目和技术社区的影响。 苏震巍：这是咱们从2013年到当初公布版本的一个流程，从3.5到6.0咱们花了很多工夫专门去切换版本，每一次都有很多咱们本人的思考， 6.0是目前为止咱们信念十分大的一个版本，微软也给了很明确的预期，咱们能够反对很长一段时间。 ...

Viyi.Strings 是一个 .NET 库，反对 .Net Standard 2.0 和 .Net 5。从名字就能看进去，这个库的次要目标是解决对字符串和文本的一些操作。总的来说，Viyi.Strings 目前的版本提供了如下一些性能： 基于文本的编/解码，反对 Base64 和 Hex（十六进制）编/解码，但不止于此；提供扩大办法对空字符串和空白字符串进行疾速解决；提供字符串大小写转换框架，并默认提供了 camelCase、PascalCase、kebab-case 和 snake_case 转换方法；在整数和字符串之间进行 2~36 进制转换，即使只想用 16 进制，也会很不便；扩大对布尔值的解析，容许 on/off、yes/no，容许灵便地自定义转换；若有其余需要，欢送在 Issue 中提出并探讨如何装置？Viyi.Strings 库曾经公布到 NuGet，能够从 NuGet 疾速装置。 基于文本的编/解码框架Viyi.String 库的 Viyi.Strings.Codec命名空间下提供了基于文本的编/解码框架。该命名空间下，不仅提供了 Base64 和 Hex 等罕用编/解码形式，还提供了对立的编/解码接口设计，为在某些场景下对立替换编/解码形式提供便当。除此之外，该命名空间下还提供了便于应用的扩大办法。 疾速 Base64/Hex 编/解码Viyi.Stings.Codec.Base64 命名空间对 byte[] 提供了 EncodeBase64() 和 DeocdeBase64() 系列扩大办法，能够迅速地在 byte[] 和 Base64 字符串之间进行编解码转换： // 随机产生 20 字节数据byte[] data = new byte[20];Random r = new Random();r.NextBytes(data);string base64;Console.WriteLine("不加参数：");Console.WriteLine(base64 = data.EncodeBase64());// 输入：RdFVrmsY45kkFKkUULem1LfCP6Y=Compare(data, base64.DecodeBase64()); // 齐全匹配Console.WriteLine("指定行宽为 16：");Console.WriteLine(base64 = data.EncodeBase64(16));// 输入：RdFVrmsY45kkFKkU// 输入：ULem1LfCP6Y=Compare(data, base64.DecodeBase64()); // 齐全匹配甚至，如果 Base64 短少最初的 = 号也是能够解码胜利的，因为 = 号原本就是示意的空数据。 ...

.NET 6正式推出已有一周多的工夫，不少小伙伴曾经装置好开始尝鲜了。围绕着.NET 6，开发者大佬们曾经为大家解说了不少新性能和新生态。然而！咱们这里还有更多你可能感兴趣的最新消息，明天就让咱们追随驰名编程杂志CODE Magazine理解一下吧！ 秒速降级至.NET 6仅需一个.NET 降级助手从 .NET Framework 过渡到 .NET 6 可能具备挑战性，因为平台之间存在差别，尤其是对于某些应用程序模型，例如 Web 应用程序，并且对于许多我的项目来说，不能齐全自动化。由此，.NET Upgrade Assistant应运而生。 降级助手是一个开源命令行工具，用于主动执行降级到 .NET 6 所需的一些更改，并突出显示须要手动进行的更改。它的指标是主动打消降级到 .NET 6 时所需的许多简略更改，以便开发人员能够专一于最乏味的局部。降级助手目前反对降级类别库、控制台应用程序、ASP.NET MVC 和 WebAPI ，以及 WinForms 和 WPF 我的项目。该工具实用于 C# (csproj) 或 VB (vbproj) 我的项目。 参考链接：https://www.codemag.com/Artic...C# 10.0精简出道全新公布的C# 10.0 摈弃了不必要的“典礼感”，比方额定的花括号或反复的代码。这些变动在将来极有可能成为C#的全新代码标准，为开发者带来更加精简的开发体验。 参考链接：https://www.codemag.com/Artic... EF Core 6，满足你的“欲望清单”Entity Framework Core 6.0的打算汇聚了许多开发者的意见，全面满足大家的“欲望清单”。全新的EF Core在查问的性能方面有了微小晋升，大部分性能改良都针对非跟踪查问。EF Core 的性能通常与 Dapper 进行比拟，Dapper 每秒返回的行数与 EF Core 5 的行数之间存在 55% 的差距。但当初，EF Core 和 Dapper 之间的差距从 55% 缩小到 4.5%，EF Core 基于 Fortunes benchmark的整体查问速度进步了 70%！“欲望清单”较长，如果你感兴趣，欢送复制上面的链接进行查阅。 ...

大家好，通过多个月的迭代，.NET 6正式版如期和大家见面了！你装置好了吗？还是等等党？心愿看完这篇文章你会对.NET 6有更多理解。 自2014年11月12日发表开源后，.NET就成为了一个跨平台、面向多场景的技术。换句话说，你能够在传统的Windows上装置.NET,也能够在Linux,macOS下装置.NET并进行云原生、桌面、挪动利用、大数据、机器学习、游戏、物联网的开发。这次更新也围绕这些场景，为不同行业进行赋能。 .NET 6是一个LTS版本，意味着你能够稳固地应用外，能够失去平安和补丁更新。依据.NET 官网上的材料，.NET 6在2023年11月都会失去长期保护，各位请安心应用。 如果你还没有/筹备装置.NET 6，请输出以下地址https://aka.ms/InstallDN下载获取更多信息。 .NET6 有不少更新，针对不同利用场景都有很多亮点，上面进行一些演绎： 1. Minimal APIMinimal API 是构建 HTTP 服务的另一种办法。 在.NET 6 通过 web 模板创立的我的项目都会应用Minimal API 。这里我得阐明一点Minimal API 不会取代大家相熟的MVC框架。 如果你的利用是心愿构建API，倡议应用web模板的形式去构建。 但如果你须要更多与ASP.NET页面相干的货色倡议还是应用MVC模板。dotnet new web -o webapidemo 看看默认Program.cs程序结构 var builder = WebApplication.CreateBuilder(args);var app = builder.Build();app.MapGet("/", () =\> "Hello World!");app.Run();你能够疾速用四行代码，实现一个API性能。当然你能够基于你的须要去增加MVC模块，验证模块等，这就看你我的项目的须要了。 更多对于 Minimal API,请点击以下链接https://aka.ms/LearnDN001 2.热更新在之前公布封版前，热更新成为了热门话题，微软作为一个商业公司可能针对社区的要求，为.NET 6 保留社区所需是十分赞的。这对于微软和开源社区接触也是一件坏事。 咱们先来意识下热更新，最晚期热更新次要是面向挪动利用，特地iOS利用更新的一种最常见的形式。不少开发者通过动静下发代码，它能够在不公布新版本的状况下，修复 BUG 和公布性能，让开发者得以绕开苹果的审核机制，防止因长时间审核期待以及屡次被拒造成的老本。我记得.NET利用热更新场景也是在Xamarin下，缓缓地大家就心愿如果代码编写能实现热更新，就能够缩小编译的工夫，即所见即所得。 在.NET 6 你能够通过Windows下的Visual Studio 2022 实现，也能够通过CLI形式实现。 通过命令行执行相干的HotReload 非常简单，你只须要在对应我的项目中执行一下命令就能够为你的Web利用实现HotReload了dotnet watch run 当然你也能够通过一下命令进行HotReload的性能dotnet watch run --no-hot-reload ...

咱们很快乐公布 .NET 6 RC(Release Candidate) 2。它是生产环境中反对的两个"go live"候选版本中的第二个。 在过来的几个月里，团队始终专一于品质的改良。这个版本中有很多的新个性，但在靠近序幕时咱们才会把他们齐全整合在一起。该团队目前正在验证端到端工作流，以找到设计用意和技术事实尚未齐全匹配的中央。这导致团队里的保护人员不得不批改bug来达到这个目标。 咱们从用户那里据说，将生产站点降级到.NET 6是既"无聊"(非事件)又"令人兴奋"(显著的性能改良)的。不出意外,咱们置信RC2将持续放弃这种趋势。 您能够下载实用于 Linux、macOS 和 Windows 的 .NET 6 Release Candidate2。 安装程序和二进制文件容器镜像Linux包公布阐明API diff已知的问题GitHub问题跟踪器请参阅 .NET MAUI和ASP.NET Core帖子，理解无关客户端和 Web 应用程序场景新增性能的更多详细信息。 .NET 大会是一个收费的，为期三天的虚构开发者流动，用来庆贺.NET的次要版本。 往年，.NET 6 将于 11 月 9 日至 11 日在 .NET 大会上公布。咱们期待您能够记下日期准时收听。Visual Studio 2022 预览版 5 也在明天公布，他们还发表将于 11 月 8 日举办公布流动。您能够在 Visual Studio 博客上浏览所有相干内容。 咱们正处于反对生产新版本的周期的这一乏味局部中。咱们真诚地激励它。如果你须要无关如何解决的领导，能够通过dotnet@microsoft.com分割咱们。许多企业曾经开始接触，有些曾经开始生产。咱们还帮忙 Microsoft 团队在 RC 版本上运行。一些 Microsoft 团队曾经在 RC1 上投入生产，咱们期待在 RC2 上有更多帮忙。这包含 .NET 网站。 .NET 6 RC2曾经通过测试，并失去了Visual Studio 2022 Preview 5的反对，也在明天公布。Visual Studio 2022将反对.NET 6， 而Visual Studio 2019不反对。同样，MSBuild 17.x将反对它，而16.x 不反对。如果你想应用.NET 6，你须要降级到Visual Studio 2022。 ...

.NET 6 是自.NET 4 框架以来生态系统看到的最大版本更新，尽管.NET Core 是2014年开始十分大的一项重大策略动作，然而.NET 6是真正的具备弱小能源的十分重要的版本。 微软MVP实验室研究员 2021年11月9日行将正式公布的.NET 6, 兴许你认为.NET 5才刚刚公布，我才刚开始应用.NET Core 3.1, .NET6 就又要公布了 ，没错的，.NET 5是2020年11月10日公布，.NET Core 3.1早在2019年12月就公布了，微软曾经承诺了每年都会公布一个版本的.NET , .NET 6正是依照时间表公布的版本。和这个版本公布节奏对应有一个反对政策：https://dotnet.microsoft.com/... 从.NET 5开始，奇数版本版本18个月修补丁周期，而偶数版本有 三年 的修补丁周期。如果您曾经将利用迁徙到.NET Core 3.1，请留神，它有一个为期三年的修补丁周期，将于 2022 年 12 月完结;如果您仍在任何之前版本的 .NET Core上，则您目前已不在反对周期内。尽管尚未发表对.NET框架 4.6.2 及当前的反对正式完结，但微软示意，.NET 框架 4.8 是.NET 框架的最初一个次要版本，将会随Windows 的反对打算更新：新的性能开发应针对以前称为 .NET Core（例如.NET 6）的平台。 .NET 6 带来了许多性能改良和生产力晋升，而且还是一个长期反对版本 。在.NET 的每个间断版本中，.NET 在执行速度和内存应用方面都获得了一些令人印象粗浅的提高。如果你始终没有跟踪， 你很可能会被. NET 框架的累积收益吹走。这一点你能够看看Techempower的测试的报告，具体参见： https://www.techempower.com/b... 变化很大咱们从 .NET 5开始向前看，作为长期反对 （LTS） 版本，.NET 6 代表着进一步的改良，并具备大量的设计和性能改良。咱们将次要看看ASP.NET 6 运行工夫的性能改良列表和.NET 6 中的中断更改，能够看到变动十分大。 C# 语言更新C#语言的最新版本是10.0，有几个乏味的变动，对于爱整洁的csharper 来说，全局援用（Global using）和 文件范畴的命名空间 是很好的互补。当初，您能够申明实用于整个编译单元（很可能是我的项目）的全局应用，并防止到每个文件顶部的去增加雷同指令集。文件范畴的命名空间还容许您申明实用于给定文件中所有代码的命名空间，无需单行无需更多匹配卷曲大括号，源文件中的凹痕级别也较少。 ...

一：背景1. 讲故事上个月中旬，星球里的一位敌人在微信找我，说他的程序跑着跑着内存会一直的迟缓增长并无奈开释，寻求如何解决 ？ 得，看样子星球还得好好弄！！！ 不管怎么说，先上 windbg 谈话。 二：Windbg 剖析1. 教训推理从敌人的截图看，有大量的 8216 字节的 byte[]，这示意什么呢？ 追寻本系列的敌人应该晓得，有一篇 某三甲医院 的内存暴涨的dump中，也同样有此 size= (8216-24=8192) 的 byte[] 数组， 他的问题是 Oracle 中读取某大字段时sdk里的 OraBuf 出了问题，换句话说，这必定又是底层或者第三方库中的池对象搞进去的货色，接下来从 托管堆 看起。 2. 查看托管堆0:000> !dumpheap -statStatistics:00007ffe107248f0 483707 15478624 System.Threading.PreAllocatedOverlapped00007ffe1079c160 483744 15479808 System.Threading.ThreadPoolBoundHandle00007ffe1079cff8 483701 23217648 System.Threading._IOCompletionCallback00007ffe106e7a90 483704 23217792 Microsoft.Win32.SafeHandles.SafeFileHandle00007ffe1079b088 483703 30956992 System.IO.FileSystemWatcher+AsyncReadState00007ffe1079ceb0 483707 34826904 System.Threading.OverlappedData00007ffe1079ccb0 483707 34826904 System.Threading.ThreadPoolBoundHandleOverlapped0000016c64651080 245652 1473128080 Free00007ffe105abf30 488172 3977571092 System.Byte[]扫完托管堆，卧槽 ，byte[] 没吸引到我，反而被 System.IO.FileSystemWatcher+AsyncReadState 吸引到了，毕竟被 System.IO.FileSystemWatcher 折腾屡次了，它曾经深深打入了我的脑海。。。毕竟让程序卡死，让句柄爆高的都是它。。。这一回八成又是它惹的祸，看样子还是有很多程序员栽在这里哈。 为做到谨严，我还是从最大的 System.Byte[] 动手，按size对它进行分组再按totalsize降序，俊俏的脚本我就不发了，间接上脚本的输入后果。 !dumpheap -mt 00007ffe105abf30size=8216,count=483703,totalsize=3790Msize=8232,count=302,totalsize=2Msize=65560,count=6,totalsize=0Msize=131096,count=2,totalsize=0Msize=4120,count=11,totalsize=0Msize=56,count=301,totalsize=0Msize=88,count=186,totalsize=0Msize=848,count=16,totalsize=0Msize=152,count=85,totalsize=0Msize=46,count=242,totalsize=0Msize=279,count=38,totalsize=0M!dumpheap -mt 00007ffe105abf30 -min 0n8216 -max 0n8216 -short0000016c664277f00000016c66432a480000016c6648ef880000016c6649daa80000016c6649fb000000016c664a8b90...从输入后果看，size=8216 的 byte[] 有 48w 个，而后脚本也列出了一些 8216 大小的 address 地址，接下来用 !gcroot 看下这些地址的援用。 ...

咱们很快乐公布 .NET 6 RC(Release Candidate) 2。它是生产环境中反对的两个“go live”候选版本中的第二个。在过来的几个月里，团队始终专一于品质的改良。这个版本中有很多的新个性，但在靠近序幕时咱们才会把他们齐全整合在一起。该团队目前正在验证端到端工作流，以找到设计用意和技术事实尚未齐全匹配的中央。这导致团队里的保护人员不得不批改bug来达到这个目标。 咱们从用户那里据说，将生产站点降级到.NET 6是既“无聊”(非事件)又“令人兴奋”(显著的性能改良)的。不出意外,咱们置信RC2将持续放弃这种趋势。 您能够下载实用于 Linux、macOS 和 Windows 的 .NET 6 Release Candidate 2。 安装程序和二进制文件 容器镜像 Linux包 公布阐明 API diff 已知的问题 GitHub问题跟踪器 请参阅 .NET MAUI 和ASP.NET Core 帖子，理解无关客户端和 Web 应用程序场景新增性能的更多详细信息。 .NET 大会是一个收费的，为期三天的虚构开发者流动，用来庆贺.NET的次要版本。往年，.NET 6 将于 11 月 9 日至 11 日在 .NET 大会上公布。咱们期待您能够记下日期准时收听。Visual Studio 2022 预览版 5 也在明天公布，他们还发表将于 11 月 8 日举办公布流动。您能够在 Visual Studio 博客上浏览所有相干内容。 咱们正处于反对生产新版本的周期的这一乏味局部中。咱们真诚地激励它。如果你须要无关如何解决的领导，能够通过dotnet@microsoft.com分割咱们。许多企业曾经开始接触，有些曾经开始生产。咱们还帮忙 Microsoft 团队在 RC 版本上运行。一些 Microsoft 团队曾经在 RC1 上投入生产，咱们期待在 RC2 上有更多帮忙。这包含 .NET 网站。 ...

大家好，我是本期的实验室研究员——痴者工良。明天我将通过试验和残缺的操作过程，向大家简略地介绍 .NET Core 中的日志和链路追踪，以及通过链路收集日志。接下来就让咱们一起到实验室中一探到底吧！ 微软MVP实验室研究员 目录.NET Core 中的日志 控制台输入非侵入式日志Microsoft.Extensions.LoggingTrace、Debug链路跟踪 OpenTracing上下文和跟踪性能分布式链路跟踪 在不同过程中跟踪在 ASP.NET Core 中跟踪OpenTracing API 和 Jaeger链路追踪实际.NET Core 中的日志与分布式链路追踪程序记录的日志个别有两种作用，故障排查、显示程序运行状态，当程序产生故障时，咱们能够通过日志定位问题，日志能够给咱们留下排查故障的根据。很多时候，往往会认为日志记录非常简单，例如很多程序员只是应用 try-catch{}捕获异样，间接输入到 .txt，然而这些日志往往无奈起到帮忙定位问题的作用，甚至日志充斥了大量垃圾内容；日志内容全靠人眼一行行扫描，或者 Ctrl+F 搜寻，无奈高效率审查日志；日志单纯输入到文本文件中，没有很好地治理日志。 接下来，咱们将一步步学习日志的编写技巧，以及 OpenTracing API 、Jaeger 分布式链路跟踪的相干常识。 .NET Core 中的日志控制台输入最简略的日志，就是控制台输入，利用 Console.WriteLine() 函数间接输入信息。 上面时一个简略的信息输入，当程序调用 SayHello 函数时，SayHello 会打印信息。 public class Hello{ public void SayHello(string content) { var str = $"Hello,{content}"; Console.WriteLine(str); }}class Program{ static void Main(string[] args) { Hello hello = new Hello(); hello.SayHello("any one"); Console.Read(); }}非侵入式日志通过控制台，咱们能够看到，为了记录日志，咱们必须在函数内编写输出日志的代码，优缺点这些就不多说了，咱们能够通过 AOP 框架，实现切面编程，同一记录日志。 这里能够应用笔者开源的 CZGL.AOP 框架，Nuget 中能够搜寻到。 ...

大略有11天没发文了，真的不是因为懒，本想前几天抽空写，不晓得为啥最近求助的敌人比拟多，一天都能拿到2-3个求助dump，早晨回来就是一顿剖析，有点意思的是大多敌人本人都剖析了几遍或者公司多年的牛皮藓问题，真的是心太累，不过也好，累那是走上坡路。 再回到正题，在一个月前，有位敌人wx找到我，他最近也在学习如何剖析dump，可能教训不是很丰盛，剖析不上来了，截图如下： 尽管dump中的问题千奇百怪，但如果要汇成大类，还是有一些法则可循的，比方：gc频繁触发，大量锁 等等，具体汇总能够观摩我的星球，好了，既然剖析不上来，那就来 windbg。 二：Windbg 剖析1. 查看CPU利用率既然报过去说cpu过高，我得用数据验证下不是，老命令 !tp 。 0:057> !tpCPU utilization: 100%Worker Thread: Total: 51 Running: 30 Idle: 0 MaxLimit: 400 MinLimit: 4Work Request in Queue: 11 Unknown Function: 6a0bbb30 Context: 1b4ca258 Unknown Function: 6a0bbb30 Context: 1b4ca618 Unknown Function: 6a0bbb30 Context: 1b4ca758 Unknown Function: 6a0bbb30 Context: 1cb88d60 Unknown Function: 6a0bbb30 Context: 1b4ca798 Unknown Function: 6a0bbb30 Context: 1b5a54d0 AsyncTimerCallbackCompletion TimerInfo@01f6e530 Unknown Function: 6a0bbb30 Context: 1b5a5a50 Unknown Function: 6a0bbb30 Context: 1cb892a0 Unknown Function: 6a0bbb30 Context: 1b4ca8d8 Unknown Function: 6a0bbb30 Context: 1cb88da0--------------------------------------Number of Timers: 1--------------------------------------Completion Port Thread:Total: 1 Free: 1 MaxFree: 8 CurrentLimit: 1 MaxLimit: 400 MinLimit: 4我去，cpu打满了，对了，这里略微揭示下， CPU utilization: 100% 指的是以后机器而不是程序，话中有话就是当机器的CPU 100% 时，并不一定是你所dump的程序造成的。 ...

为了更好地学习.NET框架，本文简略梳理了.NET体系相干内容。文中若有不精确的中央，欢送大家指出交换。 .NET简介微软于90年代开始钻研称为.NET策略的技术。20年代初，.NET框架被称为下一代Windows服务。2000年前期微软公布了.NET框架的第一个beta版本，而后于2002年2月13日公布了第一个正式版本(.NET 1.0)，之后又陆续公布了许多具备新性能的版本，要害节点如下图： .NET是微软创立的开源开发平台，应用 MIT and Apache 2 协定，属于.NET基金会。 .NET反对多种开发语言，能够应用C#、VB.NET、C++/CLI、F#等语言进行开发，不同语言的开发者能够互相配合。 应用.NET能够开发不同类型的利用，如桌面利用、挪动利用、游戏、Web利用。 应用.NET Core、.NET5及以上版本能够开发跨平台的应用程序。.NET反对不同的操作系统，如Windows、Linux、Android、iOS，反对不同架构的处理器（x86、x64、ARM32、ARM64）。 能够应用Visual Studio（Windows）、Visual Studio for Mac（macOS）、Visual Studio Code（Windows/macOS/Linux）进行开发，能够通过NuGet包管理器装置第三方依赖。 如果想理解一些基于.NET实现的解决方案，如Roslyn、dnSpy、log4net、Prism、Caliburn Micro等，能够参考此链接。 .NET体系起初，微软创立了.NET Framework，它是基于Windows的。Mono创立于2001年，它提供了.NET的另一种实现，具备跨平台的能力。为了创立跨平台的解决方案，微软推出了.NET Core。2020年末，微软公布了.NET 5，能够看到曾经去掉了Framework及Core的后缀，尔后的版本也不会再辨别Framework及Core。倒退到当初，.NET体系蕴含了上述不同的框架及其运行时。 所有运行时应用.NET提供的根底工具进行编译和运行代码，包含.NET反对的开发语言（C#、VB等）、编译器（Roslyn）、垃圾回收期（GC），以及构建工具（MsBuild）、CLR。比方，开发一款Windows客户端应用程序，能够应用C#或者VB语言编写逻辑代码，应用.NET Framework的WPF框架或WinForm框架进行界面开发。应用Visual Studio进行开发时，会调用MsBuild构建程序，它会调用Roslyn将代码编译为IL保留在程序集中（exe/dll）。在运行时，CLR中的JIT编译器会将IL编译为本机操作系统了解的代码执行，GC则负责垃圾回收。.NET的体系结构如图所示： VB C# F#能够应用VB、C#或F#等语言编写.NET应用程序。 VB是微软开发的传统面向对象编程语言，VB6.0后，引入了.NET Framework。VB深受比尔盖茨的青睐，它是最靠近人类语言的计算机编程语言。 主导C#开发的是Pascal之父、Delphi首席架构师Anders Hejlsberg。C#取义C++的++，即(C++)++，合在一起就是个#，所以读作C sharp。C#的设计思维次要借鉴了C++，Java以及Pascal，是一种面向对象的编程语言，也是目前最风行的开发语言之一。 F#是2005年微软研究院公布的一种函数式编程语言，是一种开源、跨平台、可互操作的编程语言，用于编写简洁、牢靠且性能高的代码。 .NET Framework .NET Core .NET 5.NET Framework是用来开发运行在Windows零碎下的利用的，应用了很多Windows API，目前最新版本为4.8，源码已开源。它由CLR、类库、及利用工作负载（WPF、WinForm、ASP.NET）组成。如果须要运行.NET Framework构建的利用，须要先装置相应版本的框架。同一台机器能够装置不同版本的.NET Framework。 .NET Core是开源的，2016年公布了.Net Core 1.0版本。它是为了提供跨平台的利用开发能力，并非是.NET Framework的替代品。.NET Core退出了UWP（Windows通用利用平台）框架，能够开发运行在PC、Windows Phone、Surface等所有Win 10平台的利用。不同于.NET Framework，.NET Core由CoreCLR、.NET Core类库、ASP.NET Core等组成，后续的版本也退出了WinForm、WPF等框架。.NET Core能够在不同平台上运行，它能够创立独立利用，无需在主机中装置.NET Core，但部署会比拟大。 .NET 5是2020年公布的，打算2021年11月公布.NET 6。.NET 5是.NET Core 3.1的下一个版本，因为最新的.NET Framework版本为4.8，为了防止开发者困惑，跳过了4，这也表明了.NET 5是.NET平台的将来，它将对立.NET。在.NET Core开始时，就曾经向我的项目中增加了大概五万个.NET Framework API，.NET Core 3.0进一步缩小差距，增加了WinForm、WPF、EF，.NET 5在此基础上，又集成了Mono的长处。.NET 6中将正式集成MAUI，MAUI是Xamarin.Forms的进化，应用MAUI进行开发，将能够公布到Android、iOS、Windows、macOS平台。另外，.NET 5也提供了对ARM64的反对。 ...

.NET 6 行将推出，接下来的文章中咱们将在.NET 和 ASP.NET Core 中分享一些令人惊喜的新 API，它们是由咱们杰出的 .NET 开发人员社区间接驱动的，让咱们开始逐个理解吧！ 行将推出：https://devblogs.microsoft.co...读写文件在 .NET 6 中，有一个新的 API 能够在不应用 FileStream 的状况下读取/写入文件。它还反对扩散/汇集 IO（多个缓冲区）和给定文件偏移量的笼罩读取和写入。 using Microsoft.Win32.SafeHandles;using SafeFileHandle handle = File.OpenHandle("ConsoleApp128.exe");long length = RandomAccess.GetLength(handle);Console.WriteLine(length);过程门路和 ID有几种新办法能够在不调配新过程对象的状况下拜访过程门路和过程 ID： int pid = Environment.ProcessId;string path = Environment.ProcessPath;Console.WriteLine(pid);Console.WriteLine(path);CSPNG（明码平安伪随机数生成器）从 CSPNG（明码平安伪随机数生成器）生成随机数比以往更容易： // Give me 200 random bytesbyte[] bytes = RandomNumberGenerator.GetBytes(200);Parallel.ForEachAsync咱们最终增加了 Parallel.ForEachAsync，这是一种调度异步工作的办法，可让您管制并行度： var urlsToDownload = new [] { "https://dotnet.microsoft.com", "https://www.microsoft.com", "https://twitter.com/davidfowl"};var client = new HttpClient();await Parallel.ForEachAsync(urlsToDownload, async (url, token) =>{ var targetPath = Path.Combine(Path.GetTempPath(), "http_cache", url); HttpResponseMessage response = await client.GetAsync(url); if (response.IsSuccessStatusCode) { using FileStream target = File.OpenWrite(targetPath); await response.Content.CopyToAsync(target); }})配置Helpes咱们增加了一个帮忙程序，以便在短少必须的配置局部时更容易抛出异样： ...

一：背景1. 讲故事前段时间有位敌人wx找到我，说他的程序存在内存阶段性暴涨，寻求如何解决，和敌人沟通下来，他的内存平时大略是5G 左右，在某些时点左近会暴涨到 10G+, 画个图大略就是这样。 所以接下来就是想方法给他找到那莫名微妙的 5-6G 是个啥，上 windbg 谈话。 二：Windbg 剖析1. 判断托管还是非托管从形容上看大概率是托管层面的问题，但为了文章的完整性，咱们还是用 !address -summary 和 !eeheap -gc 来看一下。 0:000> !address -summary--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalFree 1164 7f5`58f12000 ( 7.958 TB) 99.48%<unknown> 6924 a`6de84000 ( 41.717 GB) 97.90% 0.51%Stack 1123 0`16340000 ( 355.250 MB) 0.81% 0.00%Image 4063 0`1607d000 ( 352.488 MB) 0.81% 0.00%Heap 71 0`0c9ea000 ( 201.914 MB) 0.46% 0.00%TEB 374 0`002ec000 ( 2.922 MB) 0.01% 0.00%Other 13 0`001c6000 ( 1.773 MB) 0.00% 0.00%PEB 1 0`00001000 ( 4.000 kB) 0.00% 0.00%--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_PRIVATE 5423 a`87200000 ( 42.111 GB) 98.83% 0.51%MEM_IMAGE 7033 0`1e5d6000 ( 485.836 MB) 1.11% 0.01%MEM_MAPPED 113 0`01908000 ( 25.031 MB) 0.06% 0.00%--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_FREE 1164 7f5`58f12000 ( 7.958 TB) 99.48%MEM_RESERVE 4165 8`1b873000 ( 32.430 GB) 76.11% 0.40%MEM_COMMIT 8404 2`8b86b000 ( 10.180 GB) 23.89% 0.12%0:000> !eeheap -gcNumber of GC Heaps: 32------------------------------Heap 0 (00000000004106d0)generation 0 starts at 0x0000000082eb0e58generation 1 starts at 0x0000000082d79b20generation 2 starts at 0x000000007fff1000ephemeral segment allocation context: none segment begin allocated size000000007fff0000 000000007fff1000 0000000083f80128 0x3f8f128(66646312)Large object heap starts at 0x000000087fff1000 segment begin allocated size000000087fff0000 000000087fff1000 0000000883fe4190 0x3ff3190(67056016)0000000927ff0000 0000000927ff1000 000000092bfe2430 0x3ff1430(67048496)0000000a81c50000 0000000a81c51000 0000000a8221c858 0x5cb858(6076504)Heap Size: Size: 0xc53ef40 (206827328) bytes.------------------------------...Heap 31 (0000000019c84130)generation 0 starts at 0x0000000844fc5170generation 1 starts at 0x0000000844f851f8generation 2 starts at 0x000000083fff1000ephemeral segment allocation context: none segment begin allocated size000000083fff0000 000000083fff1000 0000000845171ca0 0x5180ca0(85462176)Large object heap starts at 0x00000008fbff1000 segment begin allocated size00000008fbff0000 00000008fbff1000 00000008fffe2290 0x3ff1290(67048080)000000094bff0000 000000094bff1000 000000094ea2ebb8 0x2a3dbb8(44293048)000000096bff0000 000000096bff1000 000000096dbdec00 0x1bedc00(29285376)Heap Size: Size: 0xd79d6e8 (226088680) bytes.------------------------------GC Heap Size: Size: 0x1f1986a88 (8348265096) bytes.从卦中得悉，10G的内存，托管堆吃掉了 8.3G，很显著托管层问题，晓得大方向后，接下来就能够到托管堆看一看，依据过往教训程序必定是生成了大量的类对象所致，上命令 !dumpheap -stat 。 ...

最近工作须要接触了VB开发语言，但本身对VB并不相熟，因而理解了上面向.Net的多语言开发，在此记录下。 简介.NET 是独立的语言。 这意味着，开发人员可应用面向.NET实现的多种语言（例如C#、F#和Visual Basic）进行开发。 可拜访针对 .NET 实现开发的类库的类型和成员，而不用理解它们的初始编写语言，也不用遵循任何原始语言的约定。如果你是组件开发人员，无论组件采纳哪种语言，均可由任何 .NET 利用拜访。（摘自微软官网文档） 本文次要形容C#与VB的共同开发，其它合乎CLS标准的语言相似。首先，C#与VB共同开发能够分两条路线探讨： 同一个我的项目中应用两种语言进行开发同一个解决方案，不同我的项目应用不同语言进行开发C#、VB共同开发首先，两条路线都是可行的。对于1，在同一个我的项目中应用C#和VB开发意义不是很大，C#文件的后缀为.cs，VB文件的后缀为.vb，应用VS开发时须要进行编译设置或者手动编译，不是很不便。感兴趣的能够参考微软官网文档，本文次要介绍第二条路线。 第二条路线，即同一解决方案，不同我的项目别离应用C#、VB进行开发，并能够相互调用。C#和VB都是反对.Net的，都会被编译器编译为两头语言IL，这为C#、VB共同开发提供了可能。实现这个指标很简略，甚至无需任何配置，只须要创立一个解决方案，而后创立一个VB我的项目，一个C#我的项目，并增加援用，而后就能够实现相互调用。如下进行简略的测试： class Program{ static void Main(string[] args) { double left = 3.5; double right = 4.5; var result = VBMath.Add(left, right); Console.WriteLine($"调用VB库的Add办法：{result}"); Console.ReadLine(); }}public class CSharpMath{ public static double Add(double left, double right) => left + right;}Module Program Sub Main(args As String()) Dim left As Double = 3.5 Dim right As Double = 4.5 Dim result = CSharpMath.Add(left, right) Console.WriteLine("调用C# Add办法：{0}", result) Console.ReadLine() End SubEnd ModulePublic Class VBMath Public Shared Function Add(left As Double, right As Double) As Double Return left + right End FunctionEnd Class上述测试胜利执行，能够看出C#和VB共同开发如此简略，不便了不同语言的程序员进行联合开发。然而，C#与VB毕竟是不同的语言，有些C#的个性VB不反对，反之，VB反对的某些个性C#也不反对。比方C#辨别大小写，VB不辨别。批改C#的CSharpMath类，如下： ...

一：背景1. 讲故事上个月有位敌人wx找到我，说他的程序存在内存透露问题，寻求如何解决？ 如下图所示： 从截图中能够看出，这位敌人对 windbg 的操作还是有些相熟的，可能不足肯定的实操教训，所以用了几个命令之后就不晓得怎么排查上来了。 既然找到我，那就以我的集体教训在他的dump上持续剖析寻找罪魁祸首，闲话不多说，上windbg谈话。 二：Windbg 剖析1. 真的存在内存透露吗？追这个系列的敌人应该晓得，我无数次的用 !address -summary 和 !eeheap -gc 这两个命令来判断以后的内存透露是属于托管层还是非托管层。 0:000> !address -summary--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalFree 358 7dfc`67f60000 ( 125.986 TB) 98.43%<unknown> 1087 203`88b6e000 ( 2.014 TB) 99.99% 1.57%Image 1532 0`09f11000 ( 159.066 MB) 0.01% 0.00%Heap 249 0`03453000 ( 52.324 MB) 0.00% 0.00%Stack 66 0`01fc0000 ( 31.750 MB) 0.00% 0.00%Other 10 0`001d1000 ( 1.816 MB) 0.00% 0.00%TEB 22 0`0002c000 ( 176.000 kB) 0.00% 0.00%PEB 1 0`00001000 ( 4.000 kB) 0.00% 0.00%--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_MAPPED 183 200`00d06000 ( 2.000 TB) 99.30% 1.56%MEM_PRIVATE 1252 3`8d479000 ( 14.207 GB) 0.69% 0.01%MEM_IMAGE 1532 0`09f11000 ( 159.066 MB) 0.01% 0.00%--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_FREE 358 7dfc`67f60000 ( 125.986 TB) 98.43%MEM_RESERVE 749 200`28a9b000 ( 2.001 TB) 99.33% 1.56%MEM_COMMIT 2218 3`6f5f5000 ( 13.740 GB) 0.67% 0.01%0:000> !eeheap -gcNumber of GC Heaps: 1generation 0 starts at 0x00000026DA8DA928generation 1 starts at 0x00000026DA7FC348generation 2 starts at 0x00000024C4691000ephemeral segment allocation context: none segment begin allocated size00000024C4690000 00000024C4691000 00000024D468FF28 0xfffef28(268431144)00000024EECF0000 00000024EECF1000 00000024FECF0000 0xffff000(268431360)000000248D6F0000 000000248D6F1000 000000249D6EFEF8 0xfffeef8(268431096)...00000026D66D0000 00000026D66D1000 00000026DBA3CA30 0x536ba30(87472688)Large object heap starts at 0x00000024D4691000 segment begin allocated size00000024D4690000 00000024D4691000 00000024DC67C318 0x7feb318(134132504)00000024E60F0000 00000024E60F1000 00000024EE0637C8 0x7f727c8(133638088)0000002482140000 0000002482141000 000000248A08F338 0x7f4e338(133489464)00000024A6770000 00000024A6771000 00000024AE76F6C0 0x7ffe6c0(134211264)...000000278E6D0000 000000278E6D1000 000000279635F2D0 0x7c8e2d0(130605776)00000029233E0000 00000029233E1000 000000292AF672F8 0x7b862f8(129524472)000000292B3E0000 000000292B3E1000 0000002931A5ED60 0x667dd60(107470176)000000299B3E0000 000000299B3E1000 00000029A20095B0 0x6c285b0(113411504)000000281E6D0000 000000281E6D1000 0000002825CD3F58 0x7602f58(123744088)00000028266D0000 00000028266D1000 000000282D5CAD50 0x6ef9d50(116366672)000000282E6D0000 000000282E6D1000 0000002833CA0880 0x55cf880(89979008)00000029A33E0000 00000029A33E1000 00000029A684D300 0x346c300(54969088)Total Size: Size: 0x353f96d88 (14293757320) bytes.------------------------------GC Heap Size: Size: 0x353f96d88 (14293757320) bytes.从输入看，以后过程占用 MEM_COMMIT=13.7G，托管堆内存占用 14293757320 = 13.3G，很显著这属于简略模式的 托管内存透露，依据教训，托管堆上可能有什么大对象，这里用 !dumpheap -stat 命令。 ...

一：背景1. 讲故事这个月中旬，有位敌人加我wx求助他的程序线程占有率很高，寻求如何解决，截图如下： 说实话，和不同行业的程序员聊天还是蛮有意思的，广交朋友，也能扩充本人的圈子，敌人说他因为这个bug还导致我的项目黄了一个... 哈哈，看样子是客户不买账，验收不了，害。。。早找到我，这客户不就捞回来啦，这兴许就是技术的价值吧！ 既然找到我，那就让这个挂死问题彻底隐没吧，上windbg谈话。 二：Windbg 剖析1. 查看线程状况既然敌人说线程高，那就从线程动手，用 !t 命令即可。 0:000> !tThreadCount: 1006UnstartedThread: 0BackgroundThread: 1005PendingThread: 0DeadThread: 0Hosted Runtime: no Lock DBG ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception 0 1 10c8 00000000004D89A0 2a020 Preemptive 0000000000000000:0000000000000000 00000000002f1070 0 MTA 2 2 13c0 000000000031FF70 2b220 Preemptive 0000000000000000:0000000000000000 00000000002f1070 0 MTA (Finalizer) 3 3 12cc 000000000032B780 102a220 Preemptive 0000000000000000:0000000000000000 00000000002f1070 0 MTA (Threadpool Worker) 4 5 138c 000000000039E3C0 8029220 Preemptive 00000000B6D3CCA0:00000000B6D3D260 00000000002f1070 0 MTA (Threadpool Completion Port) 6 6 106c 0000000019E562A0 3029220 Preemptive 0000000000000000:0000000000000000 00000000002f1070 0 MTA (Threadpool Worker) 8 11 7f0 0000000019F8F9E0 20220 Preemptive 0000000000000000:0000000000000000 00000000002f1070 0 Ukn 9 1949 323c 000000009AA69E40 8029220 Preemptive 00000000B6BB8AD0:00000000B6BB94E0 00000000002f1070 0 MTA (Threadpool Completion Port) 10 1637 b3c 000000009AA1C260 8029220 Preemptive 00000000B6CD4220:00000000B6CD47E0 00000000002f1070 0 MTA (Threadpool Completion Port) 11 1947 223c 000000009ADB72E0 8029220 Preemptive 00000000B6D88D68:00000000B6D89550 00000000002f1070 0 MTA (Threadpool Completion Port) 12 1968 2e74 000000009AA1E330 8029220 Preemptive 00000000B6A8CD40:00000000B6A8D300 00000000002f1070 0 MTA (Threadpool Completion Port) ... 994 313 1fa4 000000009A81FFC0 8029220 Preemptive 00000000B6BFC1B8:00000000B6BFC410 00000000002f1070 0 MTA (Threadpool Completion Port) 995 1564 18ec 000000009A835510 8029220 Preemptive 00000000B6AC1ED0:00000000B6AC2490 00000000002f1070 0 MTA (Threadpool Completion Port) 996 1581 4ac 000000001C2E36E0 8029220 Preemptive 00000000B6C51500:00000000B6C51AC0 00000000002f1070 0 MTA (Threadpool Completion Port) 997 814 2acc 000000009A73B5E0 8029220 Preemptive 00000000B6D67BF8:00000000B6D683E0 00000000002f1070 0 MTA (Threadpool Completion Port) 998 517 25dc 000000009A838990 8029220 Preemptive 00000000B6D2CA10:00000000B6D2CFD0 00000000002f1070 0 MTA (Threadpool Completion Port) 999 670 2a10 000000001C2E4400 8029220 Preemptive 00000000B6CD0490:00000000B6CD0A50 00000000002f1070 0 MTA (Threadpool Completion Port) 1000 183 1704 000000009A81F930 8029220 Preemptive 00000000B6AE8670:00000000B6AE8C30 00000000002f1070 0 MTA (Threadpool Completion Port) 1001 117 1bcc 000000009A73BC70 8029220 Preemptive 00000000B6B92780:00000000B6B92D40 00000000002f1070 0 MTA (Threadpool Completion Port) 1002 1855 1d68 000000009A81E580 8029220 Preemptive 00000000B6B28460:00000000B6B28A20 00000000002f1070 0 MTA (Threadpool Completion Port) 1003 1070 2ef0 000000009A73C300 8029220 Preemptive 00000000B6B8F640:00000000B6B8FC00 00000000002f1070 0 MTA (Threadpool Completion Port) 1004 1429 210c 000000001C2E4A90 8029220 Preemptive 00000000B6D5F488:00000000B6D5FC70 00000000002f1070 0 MTA (Threadpool Completion Port) 1005 1252 2f38 000000009A838300 8029220 Preemptive 00000000B6A99240:00000000B6A99800 00000000002f1070 0 MTA (Threadpool Completion Port) 1006 1317 3118 000000001C2E5120 8029220 Preemptive 00000000B6DA3A30:00000000B6DA4440 00000000002f1070 0 MTA (Threadpool Completion Port) 1007 1837 3120 000000009A8375E0 8029220 Preemptive 00000000B6D38F10:00000000B6D394D0 00000000002f1070 0 MTA (Threadpool Completion Port) 1009 1964 2f64 000000009A81DEF0 1029220 Preemptive 0000000000000000:0000000000000000 00000000002f1070 0 MTA (Threadpool Worker) 能够看到以后有 1006 个线程，其中 1000 个是 Threadpool Completion Port，这么多IO线程卡死也是第一次遇到，。 ...

本文首发于 码友网 -- 《NuGet是什么？为什么.NET我的项目中会有NuGet？如何应用NuGet程序包？》 概述大家好，我是专一.NET开发的码友网创建者Rector。 在.NET应用程序编程开发中，开发者通常应用类库来治理、保护属于同一分类的程序代码，以便代码的重用。个别状况下，处于同一类库的所有类都位于同一程序集。 这些类库被编译器编译后会生成扩大名为.dll的动态链接库文件，你能够在其它我的项目中通过援用的形式导入这些.dll程序集并应用其中被封装的类及成员。 但随着我的项目越来越大、越来越多，应用手动援用.dll动态链接库的形式让程序包治理和保护变得十分艰难。在这种状况下，NuGet程序包管理工具便应运而生。 NuGet程序包就好比前端开发中的npm包，Java开发中的Maven或者Gradle，它们都是治理本人语言畛域的程序依赖包的工具。负责管制程序包版本，保护包与包之间的依赖，有了包管理工具，你能够疾速地安装包，还原包等。 在正式接触NuGet程序包工具前，先来一步一步回顾.NET我的项目中程序包引入的进化历。 引入程序集的形式引入程序集的形式有多种，如： 程序集在同一个解决方案，间接援用我的项目程序集在本地磁盘，浏览.dll文件引入NuGet程序包管理工具装置1.援用我的项目形式如果以后有一个名为NugetDemo.Payment的类库我的项目和一个名为ConsoleApp的控制台应用程序，现须要在ConsoleApp我的项目中通过援用我的项目的形式引入NugetDemo.Payment，办法如下： 1.右键单击依赖项，点击增加我的项目援用，如图： 2.在弹出的援用管理器窗口中选中NugetDemo.Payment，点击确定，如图： 3.Visual Studio将把选中的我的项目增加到以后我的项目的依赖项->我的项目列表，如图： 2.浏览文件形式还是在ConsoleApp我的项目中，如果有另外一个支付宝的程序集，如图： 1.还是按归援用我的项目的形式，右键单击依赖项，点击增加我的项目援用 2.在弹出的援用管理器窗口选中浏览，如图： 3.再点击右下角的浏览按钮，在文件资源管理器中找到方才筹备的Ali.Alipay.dll文件，如图： 4.抉择后点击右下角的增加按钮，将主动回到如下界面： 5.选中方才浏览的Ali.Alipay.dll，最初点击右下角的确定按钮，Visual Studio将会把这个.dll文件增加到以后我的项目的依赖项->程序集列表中，如图： 无可非议，以上的两种援用程序集的形式在后果上是没有问题的。但这种形式只适宜集体我的项目，当你的团队成员或者团队我的项目达到一定量级之后，程序集的治理、保护、版本控制等问题会让你头疼。 到最初，你可能不晓得以后援用的程序集是哪个版本？在哪里能够找到正确的程序集版本？它们之间的依赖关系是怎么样的？如果共享程序集？ 有了NuGet程序包之后，这些问题就迎刃而解。 NuGet程序包NuGet程序包是微软为.NET(包含.NET Core)平台提供的程序集共享包。 简略地说，NuGet包是一个扩大名为.nupkg的ZIP文件，其中蕴含了已编译代码(.dll)与该代码相干的其余文件，以及包版本号等信息的形容信息。 开发人员能够创立代码共享的程序包并将其公布到公共或公有主机。包使用者从适合的主机取得这些包，将它们增加到他们的我的项目中，而后在他们的我的项目代码中调用包的性能。而后NuGet本人解决所有两头细节(包含装置、卸载、依赖关系保护，版本控制等)。 微软官网为公共的.NET共享程序包提供专门的私有托管服务，地址为: https://www.nuget.org/ 目前有超过25万的程序包被分享在这里，如图： NuGet除了反对公共的nuget.org主机外还反对公有主机，所以你能够搭建集体或者公司外部的NuGet公有服务器，以达到外部分享程序包的目标。 NuGet程序包的装置和卸载治理NuGet程序包的形式有多种，其中最罕用的别离为：一、通过NuGet包管理器；二、通过命令行治理。其中NuGet包管理器是Visual Studio或者Rider这样的集成开发环境才具备的客户端管理工具。 上面以Visual Studio 2022 预览版(17.0.0 Preview 3.1)为例演示。 NuGet包管理器装置NuGet如果以后有一个基于.NET 5的控制台应用程序，构造如下： 现须要在这个控制台中装置Newtonsoft.Json以便进行json序列化和反序列化操作。那么，咱们能够通过右键依赖项 -> 治理NuGet程序包来关上NuGet包管理器，如下图： 而后抉择浏览选项卡，并在搜寻框中键入关键词，在搜寻后果中选中须要装置的程序包，最初点击右侧的装置按钮，如下： 在弹出的对话框中，点击确定按钮： Visual Studio将主动下载选中的程序包及其依赖包，并将其增加到以后我的项目的依赖项中，如下图： 当初，能够在这个ConsoleApp1我的项目中调用Newtonsoft.Json组件所有可拜访的性能了，以下示例演示了利用Newtonsoft.Json将一个json字符串反序列化成实体对象，代码如下： using Newtonsoft.Json;class Program{ static void Main(string[] args) { // 模仿一个JSON字符串 var json = "{\"id\":1,\"name\":\"Rector\",\"age\":18}"; // 调用JsonConvert.DeserializeObject<T>()泛型办法反序列化 var person = JsonConvert.DeserializeObject<Person>(json); Console.WriteLine(person.ToString()); Console.ReadKey(); }}/// <summary>/// 定义一个与JSON字符串字段匹配的实体类/// </summary>public class Person{ public int Id { get; set; } public string Name { get; set; } public short Age { get; set; } /// <summary> /// 重写ToString()办法 /// </summary> /// <returns></returns> public override string ToString() { return $"id:{Id},name:{Name},age:{Age}"; }}运行后果如下图： ...

一：背景1. 讲故事上个月有位敌人加wx告知他的程序有挂死景象，询问如何进一步剖析，截图如下： 看这位敌人还是有肯定的剖析根底，可能玩的少，不足肯定的剖析教训，当我简略剖析之后，我发现这个dump挺有意思的， CPU，内存，挂死 三样全占，程序悲惨莫过于此。。。 既然找到我，我得想方法化解他的苦楚，由易到难咱们逐个剖析这三样都是因为什么起因所致？ 二：三高剖析1. 挂死起因依据 40+ 的dump剖析教训，挂死大多是因为某种状况导致线程卡死，导致后续申请沉积在 threadpool 中，要想验证，能够应用 !tp 命令查看线程池队列。 0:000> !tpCPU utilization: 81%Worker Thread: Total: 65 Running: 65 Idle: 0 MaxLimit: 32767 MinLimit: 64Work Request in Queue: 2831 Unknown Function: 00007ffffcba1750 Context: 0000022ab04d4a58 Unknown Function: 00007ffffcba1750 Context: 0000022ab03e4ce8 ... Unknown Function: 00007ffffcba1750 Context: 0000022ab825ec88 Unknown Function: 00007ffffcba1750 Context: 0000022ab825a458 Unknown Function: 00007ffffcba1750 Context: 0000022ab8266500 Unknown Function: 00007ffffcba1750 Context: 0000022ab8268198 Unknown Function: 00007ffffcba1750 Context: 0000022ab826cb00 Unknown Function: 00007ffffcba1750 Context: 0000022ab8281578--------------------------------------Number of Timers: 0--------------------------------------Completion Port Thread:Total: 2 Free: 2 MaxFree: 128 CurrentLimit: 2 MaxLimit: 32767 MinLimit: 64能够很显著的看到线程池队列有 2831 个工作沉积，这就导致新进来的申请无奈失去解决，所以就呈现了挂死景象，接下来就来看看这些线程都干嘛去了，为啥效率那么低，能够用 ~*e !clrstack 调出所有线程栈，截图如下： ...

一：背景1. 讲故事说实话，这篇dump我原本是不筹备上一篇文章来解读的，但它有两点深深的打动了我。 无数次的据说用 Unity 可做游戏开发，但百闻不如一见。游戏中有很多金庸武侠小说才有的名字，太赏心悦目了。000000df315978a8 0 3 玉骨扇000000df31597cd8 0 3 云龙枪000000df31596d88 0 3 阴风爪000000df315967a8 0 4 雪魂丝链000000df31596ad0 0 4 乙木神剑000000df31596040 0 3 星耀冠000000df31595328 0 3 乌金锤...所以说这么好的一个dump，我得给它留下点什么。 好了，话说回来这个缘分起于上个月有位敌人说它的程序虚拟内存占用十分大，征询如何解决，如下图： 先甭管是什么问题，多抓几个dump总不会错的，几经折腾后发了一个dump过去。 二： Windbg 剖析1. 到底是哪里的透露剖析内存方面的问题，还是那句话，一分为二看一下到底是哪一块的内存透露（托管还是非托管）。 先看一下过程总内存，应用 !address -summary 命令。 0:087> !address -summary--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalFree 458 7ffe`9e6a8000 ( 127.995 TB) 100.00%Heap 48514 1`005fd000 ( 4.006 GB) 72.51% 0.00%<unknown> 2504 0`2c6ad000 ( 710.676 MB) 12.56% 0.00%Stack 504 0`2a000000 ( 672.000 MB) 11.88% 0.00%Image 410 0`0a971000 ( 169.441 MB) 3.00% 0.00%Other 18 0`001dc000 ( 1.859 MB) 0.03% 0.00%TEB 168 0`00150000 ( 1.312 MB) 0.02% 0.00%PEB 1 0`00001000 ( 4.000 kB) 0.00% 0.00%--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_PRIVATE 51581 1`5130f000 ( 5.269 GB) 95.36% 0.00%MEM_IMAGE 416 0`0aa6b000 ( 170.418 MB) 3.01% 0.00%MEM_MAPPED 122 0`05bce000 ( 91.805 MB) 1.62% 0.00%--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_FREE 458 7ffe`9e6a8000 ( 127.995 TB) 100.00%MEM_COMMIT 51465 1`1c741000 ( 4.445 GB) 80.45% 0.00%MEM_RESERVE 654 0`45207000 ( 1.080 GB) 19.55% 0.00%从卦中得悉 MEM_COMMIT=4.4G, 接下来再看下托管堆的内存占用，能够用命令 !eeheap -gc 命令。 ...

往年5月，在 Build大会上，Azure FunctionsOpenAPI的性能反对（预览版）正式发表。 过后，它最高反对 v3 运行时——.NET Core 3.1 版本。 最近，它公布了 .NET 5 隔离工作器反对包作为预览。在这篇文章中，我将回顾如何应用它并将其部署到 Azure。 留神：您能够在此 GitHub 存储库中找到本文中应用的示例代码：https://github.com/justinyoo/azfunc-openapi-dotnet在 .NET 5 中创立 Azure Functions 应用程序让咱们应用Visual Studio来实现这个练习。在创立应用程序时，应用".NET 5(隔离)"运行时和"Http触发器"。 而后您将找到带有默认代码的HTTP端点。当初，在解决方案资源管理器上抉择NuGet包管理器菜单。 在NuGet包管理器屏幕中，勾选"包含预公布"复选框，而后搜寻Microsoft.Azure.Functions.Worker.Extensions.OpenApi包。在撰写本文时，NuGet打包程序版本是v0.8.1-preview。 OpenAPI扩大当初曾经装置。 配置 HostBuilder装置OpenAPI扩大之后，让咱们配置HostBuilder。首先，关上Program.cs文件并删除现有的ConfigureFunctionsWorkerDefaults()办法。这是因为该办法默认应用System.Text.Json，咱们不会应用它。 public static void Main(){ var host = new HostBuilder() // 删除以下这行 .ConfigureFunctionsWorkerDefaults() // 删除以上这行 .Build(); host.Run(); }而后，按此程序增加ConfigureFunctionsWorkerDefaults(worker =\&gt; worker. usenewtonsoftjson())和ConfigureOpenApi()办法。第一个办法明确申明要应用Newtonsoft.Json包，下一个导入额定的OpenAPI相干端点。 public static void Main() { var host = new HostBuilder() // Add these lines below .ConfigureFunctionsWorkerDefaults(worker => worker.UseNewtonsoftJson()) .ConfigureOpenApi() // Add these lines above .Build(); host.Run();}留神：目前，应用 System.Text.Json 并不能保障应用程序是否失常工作。 因而，强烈推荐应用 Newtonsoft.Json。至此，配置结束。 让咱们持续。 ...

一：背景1. 讲故事最近在剖析一个 dump 的过程中发现其在 gen2 和 LOH 上有不少size较大的free，认真看了下，这些free生前大多都是模板引擎生成的html片段的byte[]数组，当然这篇我不是来剖析dump的，而是来聊一下，当托管堆有很多length较大的 byte[] 数组时，如何让内存利用更高效，如何让gc老先生压力更小。 不晓得大家有没有发现在 .netcore 中减少了不少池化对象的货色，比方： ArrayPool，ObjectPool 等等，的确在某些场景下还是特地实用的，所以有必要对其进行较深刻的了解。 二： ArrayPool 源码剖析1. 一图胜千言在我花了将近一个小时的源码浏览之后，我画了一张 ArrayPool 的池化图，所谓：一图在手,天下我有 。 有了这张图，接下来再聊几个概念并配上相应源码，我感觉应该就差不多了。 2. 池化的架构分级是什么样的？ArrayPool 是由若干个 Bucket 组成， 而 Bucket 又由若干个 buffer[] 数组组成, 有了这个概念之后，再配一下代码。 public abstract class ArrayPool<T>{ public static ArrayPool<T> Create() { return new ConfigurableArrayPool<T>(); }}internal sealed class ConfigurableArrayPool<T> : ArrayPool<T>{ private sealed class Bucket { internal readonly int _bufferLength; private readonly T[][] _buffers; private int _index; } private readonly Bucket[] _buckets; //bucket数组}3. 为什么每一个 bucket 里都有 50 个 buffer[]这个问题很好答复，初始化时做了 maxArraysPerBucket=50 设定，当然你也能够自定义，具体参考如下代码： ...

一：背景1. 讲故事上上周有位敌人找到我，说他的程序CPU和句柄都在一直的增长，无回头趋势，查了好些天也没什么停顿，特加wx寻求帮忙，截图如下： 看的进去这位敌人也是十分郁闷，出问题还出两个，气人哈，对于 cpu 爆高的问题我筹备独自用一篇文章去侦读，这篇就先聊聊 句柄透露 的问题，毕竟写了20多篇，也是第一次聊到 handle 泄露，有点意思哈。 2. 什么是句柄我集体了解的句柄：就是在托管层持有了一个对非托管层资源的援用，有了这个援用，咱们就能够强制回收非托管资源，那什么是非托管资源？ 我集体的了解是 gc 管不到的中央都是 非托管资源。 通常蕴含这种句柄的类有： FileStream, Socket 等，如果大家有这个前置根底，接下来就能够用 windbg 去剖析啦！ 二： windbg 剖析1. 看问题表象敌人从 工作管理器 中看到 handle =8770，那就阐明程序中有 8770 个对非托管资源持有句柄，那怎么去看呢? 在说这个之前，大家有没有遇到这种景象，就是不论程序怎么透露，只有咱们退出exe，那么所有的资源都会被神奇的 开释, 不论是托管资源还是非托管资源，这样说置信有很有敌人好奇这是怎么实现的？？？ 大家能够先想 10s。 揭晓答案啦！ 简略的说, CLR 在外部保护了一张句柄表，当程序敞开时，CLR会强制开释句柄表中的所有句柄，那问题就简略了，既然 CLR 能触达，我置信通过 windbg 也能做到，对，就是通过 !gchandles 命令。 2. 查看句柄表这里揭示一下，!gchandles 的作用域是 AppDomain，而不是 Process，接下来看一下命令输入： 0:000> !gchandles -statStatistics: MT Count TotalSize Class Name...00007ffccc1d2360 3 262280 System.Byte[]00007ffccc116610 72 313224 System.Object[]00007ffccc3814a0 8246 593712 System.Threading.OverlappedDataTotal 10738 objectsHandles: Strong Handles: 312 Pinned Handles: 18 Async Pinned Handles: 8246 Ref Count Handles: 1 Weak Long Handles: 2080 Weak Short Handles: 59 Dependent Handles: 22从输入看，有一组数据特地扎眼，那就是： Async Pinned Handles = 8246 [System.Threading.OverlappedData]，这是什么意思呢？ 从英文名就能看出这是一个和 异步IO 相干的句柄，有些敌人应该晓得，在异步IO的过程中，会有一个 byte[] 被 pinned 住，同时还有一个异步IO的上下文对象 OverlappedData。 ...

咱们很快乐发表.NET 6 预览版6问世啦。预览版6 是咱们RC版公布之前的倒数第二个预览版。 咱们将有两个RC版。 此版本自身绝对较小，而预览版7会更大。 在那之后，咱们将进行品质修复，直到11 月的最终版本。 咱们期待一个很棒的新.NET 版本。 您能够下载实用于Linux、macOS 和Windows 的.NET 6 预览版 6。 安装程序和二进制文件容器镜像Linux 软件包发行阐明API差别已知的问题GitHub 问题跟踪器请参阅ASP.NET Core、EF Core和.NET MAUI文章来理解更多对于Web、数据拜访和客户端计划的新性能。 从.NET 6 预览版6 开始，咱们曾经测试并反对Visual Studio 2022 预览版2。Visual Studio 2022是您能够用来开发.NET 6的开发工具，例如 .NET MAUI 开发、C# 应用程序的热重载、 用于WebForms 的新Web 实时预览，以及IDE 体验中的其余性能改良。.NET 6 也在Visual Studio for Mac 8.9进行了测试。 查看新的对话帖子，以深刻理解工程师对最新.NET 性能的探讨。 x64 仿真更新咱们曾经实现了对macOS 的Apple Silicon 和Windows 的Arm64 的反对。 剩下的就是在macOS Apple Silicon和Windows Arm64上反对x64 仿真。 咱们须要做两件事来实现这一点。 并排安装程序以.NET CLI 为指标的一流架构（次要）反对在各种场景中应用本机架构SDK。在能够应用并排安装程序之前（之后在.NET 6 中），您须要装置所有x64 版本或者所有Arm64 版本。 如果要切换，须要卸载/删除Arm64 机器上的所有.NET 版本。 很道歉，目前在这个阶段只能这样实现。 ...

一：背景1. 讲故事七月中旬有一位敌人加wx求助，他的程序在生产上跑着跑着内存就飙起来了，貌似没有回头的趋势，询问如何解决，截图如下： 和这位敌人聊下来，感觉像是本人在小县城当了个小老板，法则的生存，有当地资源，各种小关系，有一股财务自在的滋味，这也是我始终向往的生存形式 。 既然敌人找到我了，我得想方法给他解决问题，既然是内存暴涨，我就赌一把在托管层面吧，嘿嘿，上windbg谈话。 二： windbg 剖析1. 托管还是非托管始终在追这个系列的敌人应该晓得，我无数次的用 !address -summary 和 !eeheap -gc 这两个命令来判断以后内存属于托管层还是非托管层。 0:000> !address -summary--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_FREE 393 7dfe`f2105000 ( 125.996 TB) 98.43%MEM_RESERVE 1691 200`0f1e4000 ( 2.000 TB) 99.81% 1.56%MEM_COMMIT 6191 0`fed07000 ( 3.981 GB) 0.19% 0.00%0:000> !eeheap -gcNumber of GC Heaps: 1generation 0 starts at 0x000001D2E572BBC8generation 1 starts at 0x000001D2E54F70E0generation 2 starts at 0x000001D252051000ephemeral segment allocation context: none segment begin allocated size000001D252050000 000001D252051000 000001D26204FFE0 0xfffefe0(268431328)Large object heap starts at 0x000001D262051000 segment begin allocated size000001D262050000 000001D262051000 000001D2655F3F80 0x35a2f80(56242048)Total Size: Size: 0xbf4dbf80 (3209543552) bytes.------------------------------GC Heap Size: Size: 0xbf4dbf80 (3209543552) bytes.卦象上过程指标为 3.98G ，GC堆指标为 3209543552 = 3G ，很显然，本次事变属于 托管层面。 ...

最近，咱们公布了.NET 多平台应用程序UI (MAUI)的最新进展。 在此版本中，咱们全力支持Visual Studio 2022 预览版2。这也标记着咱们首次将.NET MAUI 作为工作负载装置公布。 当初提供了一些新性能，包含手势、模态页面、视图剪辑、本机正告、灵便布局等。 随着采纳最新版本的Windows 应用程序SDK 和Visual Studio 扩大，单个我的项目也持续失去改良。 让咱们更深刻地理解一下。 工作负载装置作为.NET 对立的一部分，咱们引入了SDK 工作负载的概念，以在您装置的.NET SDK 之上启用特定的开发人员场景。 在预览版4 中，启用了实用于Android、iOS、macOS 和Mac Catalyst 的底层SDK，当初在预览版6 中，咱们引入了maui、maui-mobile 和maui-desktop 工作负载。 这是第一个将获取并装置构建.NET MAUI 应用程序所需的所有SDK。 如果您只想定位到挪动设施或桌面设施，您能够独自抉择它们。 在不久的未来，Visual Studio 2022 将在其安装程序中蕴含这些。 要立刻应用它们，请跳转到您最喜爱的CLI。 首先，看看你曾经装置了什么： dotnet sdk check 这会报告通过.NET SDK 安装程序自身装置的内容。 当初查看运行的额定工作负载： dotnet workload list 而后装置.NET MAUI，您能够执行： dotnet workload install maui maui-check dotnet 工具怎么样？咱们将持续在每个版本中更新maui-check，因为它会对您的开发环境进行额定验证以帮忙您取得成功：查看OpenJDK、模拟器、Xcode、Visual Studio 版本等。无关挪动和桌面工作负载的更多信息，请在此处浏览详细信息。 新的.NET MAUI 性能正如您在咱们的状态报告中所看到的，咱们的性能越来越欠缺，快要靠近全绿了， 让咱们重点介绍一些吧。 手势手势识别器容许您将点击、捏合、平移、滑动和拖放利用于任何视图实例。您能够在XAML 中轻松利用它们： <Grid> <Grid.GestureRecognizers> <TapGestureRecognizer NumberOfTapsRequired="2" Command="{Binding OnTileTapped}" /> </Grid.GestureRecognizers> <!-- Grid content --></Grid> ...

一：背景1. 讲故事七月底的时候有位敌人在wx上找到我，说他的程序内存占用8G，托管才占用1.5G，询问剩下的内存哪里去了？截图如下： 从求助内容看，这位敌人真的太客气了，动不动就谈钱，真伤感情，如果有敌人始终关注我的分享，应该晓得我始终都是收费剖析dump，当然我的常识和教训也是有边界的，有些dump我也搞不定，不过我还是尽本人最大致力去寻找答案。 在这里我有必要说一下职场，在我的潜意识或者在我的团队中，这些很难搞的问题当然由技术领导去搞定，但我发现有好几起却不是这样的，技术经理搞不定转包下来，上面搞不定就让他另请高明。。。 有大佬能够剖析下吗。 好了，闲话不多说，事不宜迟上windbg谈话。 二： windbg 剖析1. 真的是非托管透露吗？我在很多剖析内存透露方面的文章都提到过，先要用二分法确定下是哪一部分的内存透露（托管还是非托管）。 0:000> !address -summary--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalFree 387 7df2`11ac1000 ( 125.946 TB) 98.39%<unknown> 2229 20c`a21bb000 ( 2.049 TB) 99.75% 1.60%Heap 1081 1`33914000 ( 4.806 GB) 0.23% 0.00%Image 1674 0`0e4be000 ( 228.742 MB) 0.01% 0.00%Stack 973 0`0a140000 ( 161.250 MB) 0.01% 0.00%TEB 324 0`00288000 ( 2.531 MB) 0.00% 0.00%Other 11 0`001d9000 ( 1.848 MB) 0.00% 0.00%PEB 1 0`00001000 ( 4.000 kB) 0.00% 0.00%--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_MAPPED 300 200`00f9e000 ( 2.000 TB) 97.35% 1.56%MEM_PRIVATE 3869 d`dd7ed000 ( 55.461 GB) 2.64% 0.04%MEM_IMAGE 2124 0`0fda4000 ( 253.641 MB) 0.01% 0.00%--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_FREE 387 7df2`11ac1000 ( 125.946 TB) 98.39%MEM_RESERVE 1763 20b`d9903000 ( 2.046 TB) 99.60% 1.60%MEM_COMMIT 4530 2`14c2c000 ( 8.324 GB) 0.40% 0.01%0:000> !eeheap -gcNumber of GC Heaps: 40------------------------------Heap Size: Size: 0x3322e60 (53620320) bytes.------------------------------GC Heap Size: Size: 0x603046b0 (1613776560) bytes.从 !address -summary 和 !eeheap -gc 两条命令看，的确如敌人所说：MEM_COMMIT=8.3G， GC Heap=1.5G， 我去，果然是难搞的非托管内存透露，既然是天堂模式，那就硬着头皮持续看吧，要想持续排查的话，首先得看 windows nt 堆。 ...

在这篇文章中，咱们将解决一些常见的Blazor问题。具体来说就是"什么是Blazor"，但更重要的是"为什么要用Blazor"。既然咱们曾经有了Angular、React、Vue或其余一些JavaScript框架，为什么还要关注Blazor 以及为什么要抉择Blazor? WebAssembly又是对于什么的?咱们将介绍微软的web利用程序开发框架的历史，以及咱们对其光明前景的瞻望。 什么是 BlazorBlazor有几个常见的定义，第一个非常简单: Blazor是一个用.NET构建交互式客户端web UI的框架。-微软文档:Blazor正如官网文档所述，它首先是一个"框架"——它被用来构建客户端web UI。但它与其余用于构建web UI的客户端框架有何不同?是什么让它如此特地? 我心愿你会问本人：".NET 有什么不同吗？" 这是另一个定义: Blazor是一个收费和开源的web框架，开发者能够应用c#和HTML创立web应用程序。"——维基百科:Blazor哦，它是收费的——这很好。 但偏心地说，还有很多其余收费框架可用于构建客户端 Web UI。 我为什么要关怀 Blazor？ 为什么是Blazor？从历史上看，微软之前所有的web UI框架都是基于齐全不同的架构，并在服务器端出现。Blazor着手将c#开发引入web客户端，这只有在WebAssembly呈现时才可能实现。 WebAssembly(缩写为Wasm)是一种用于基于堆栈的虚拟机的二进制指令格局。Wasm被设计为编程语言的可移植编译指标，使客户端和服务器应用程序可能在web上部署。" ——webassembly.org哇，听起来很拗口!让咱们来剖析一下: 在这种状况下，"二进制指令格局"意味着它是字节代码，从非javascript编程语言中提取形象语法树(AST)并将其转换为二进制。 Wasm位于"基于堆栈的虚拟机"之上——这标识了基于"推送"⬇ 和"弹出"⬆ 的外围性能。指令被推送，评估被弹出。尽管这是一种适度简化，但概念依然存在，实现细节并不那么重要。单线程、利用内存束缚等都有一些限度，然而Blazor治理与Wasm的互操作时没有强调这些限度。 请留神Wasm是一个"可移植编译指标"，这一点十分重要。这意味着能够应用C、C++、Rust、C#和其余非传统的Web编程语言，并以Wasm为指标进行编译。这就产生了Wasm二进制文件，它基于凋谢规范，但来自JavaScript以外的编程语言。 简言之，Blazor可与JavaScript互操作，甚至有不同的托管模型——服务器端和Wasm的客户端。稍后会具体介绍…… 什么是 JavaScript?Wasm是JavaScript的终结吗，这意味着什么?答案是否定的。JavaScript不会隐没——Wasm应该被认为是JavaScript的补充。 预计JavaScript和WebAssembly将在许多配置中一起应用。——webassembly.org:常见问题解答类比感激 Wasm，网络浏览器的一些局限性失去改善，这也是为什么我置信： "有了 WebAssembly，网络浏览器更像是应用程序商店——最终用户体验更靠近原生性能。" ——大卫·松 仿佛有有数特定于Wasm的新案例无奈独自应用JavaScript实现。很容易设想应用程序通过web交付到您的浏览器，由Wasm提供更简单和资源密集型的案例。这就是为什么我认为这是web利用平台可能实现的范式转变。 采纳Wasm在所有支流浏览器中都失去了反对，并且笼罩了简直93%的所有用户——我能够应用"WebAssembly"吗?这与Silverlight所依赖的基于插件的办法不同。这是web的将来，您将持续看到开发人员应用这种技术构建应用程序。 安全可靠Wasm和JavaScript一样平安。 WebAssembly形容了一个内存平安的、沙箱执行环境，它甚至能够在现有的JavaScript虚拟机中实现。当嵌入到web中时，WebAssembly将强制浏览器的同源和权限安全策略。"——webassembly.org换句话说，Wasm被限度在与JavaScript雷同的平安沙箱中。 Web利用平台通过古代 Web 利用程序开发，您心愿您的应用程序在桌面和挪动浏览器上都能响应。古代 Web 应用程序比它们的前辈更加简单和丰盛，具备一些预期性能，包含实时 Web 性能、渐进式 Web 应用程序 (PWA) 性能和精心编排的用户交互。 .NET 开发人员第一次能够应用他们现有的 C# 技能在 Web 上构建各种应用程序。在我看来，这有助于含糊后端和前端开发人员之间的界线——但更宽泛地通过web扩大利用程序开发。我置信在客户端和服务器上应用雷同的编程语言的理念会促成用户更快的采纳，特地是 Node.js。 相熟你兴许可能很容易接受能够应用现有的C#技能进行开发，但也容易疏忽这个事实：HTML、CSS和JavaScript依然存在并可用。通过这些，您能够持续应用您的HTML和CSS技能、您最喜爱的CSS库，并且能够轻松地应用现有的JavaScript包。毕竟，您依然在构建web应用程序! 简史早在 1996 年，Active Server Pages (ASP)就为 Microsoft 的动静网页提供了第一个服务器端脚本语言和引擎。随着 .NET Framework 的倒退，ASP.NET 诞生了，随之而来的是 Web Forms。 Web Forms 已经（当初依然）被许多喜爱 .NET 性能的人应用，它容许在服务器端出现 HTML。 ...

很快乐.NET 6 预览版5终于跟大家见面了。咱们当初正处于.NET 6 的后半局部，开始整合一些重要的性能。 例如.NET SDK 工作负载，它是咱们.NET 对立愿景的根底，能够反对更多类型的应用程序。 与其余性能一样，它也是为了更好地服务于端到端的用户体验。 您能够下载实用于Linux、macOS 和Windows 的.NET 6 预览版5。 安装程序和二进制文件容器镜像Linux 软件包发行阐明API差别已知的问题GitHub 问题跟踪器请参阅ASP.NET Core、EF Core以及.NET MAUI，理解无关Web、数据拜访和跨平台UI 计划新增性能的更多详细信息。 Visual Studio 2022 预览版1 也在明天公布，.NET 6 预览版5蕴含其中。.NET 6 还在Visual Studio 16.11和Visual Studio for Mac 8.9进行了测试。 如果您想在Visual Studio中试用.NET 6，咱们建议您应用这些版本。 您也能够查看新的对话帖，深刻理解工程师们对.NET新性能的想法。 .NET SDK：可选的工作负载改良SDK 工作负载是一项新的.NET SDK 性能，它使咱们可能在不减少SDK 大小的状况下增加对新应用程序类型（如挪动和WebAssembly）的反对。 工作负载增加了包含list 和update 指令。这些新性能提供了与咱们冀望的最终体验统一的应用感触。您将可能应用一些简略的指令疾速构建您的环境，并始终将其放弃最新状态。 dotnet workload list 会告诉您装置了哪些工作负载。dotnet workload update 会将所有已装置的工作负载更新到最新的可用版本。update 指令会查问nuget.org 以获取更新的工作负载清单、更新本地清单、下载已装置工作负载的新版本，而后删除工作负载的所有旧版本。这相似于apt update 和apt upgrade -y（用于基于Debian 的Linux 发行版）。 dotnet workload 命令集在给定SDK 的上下文中运行。假如您同时装置了.NET 6 和.NET 7。如果您同时应用两者，则工作负载命令将提供不同的后果，因为工作负载会有所不同（至多是雷同工作负载的不同版本）。 ...

一：背景1. 讲故事大略有两个月没写博客了，关注我的敌人应该晓得我最近都把精力花在了星球，这两个月工夫也陆陆续续的有敌人求助如何剖析dump，有些敌人太客气了，给了大大的红包，哈哈，手外面也攒了10多个不同问题类型的dump，后续也会逐个将剖析思路奉献进去。 这个dump是一位敌人大略一个月前提供应我的，因为wx外面求助的敌人比拟多，一时也没找到相干截图，不得已毁坏一下老规矩。 既然敌人说api接口无响应，出现了hangon景象，从一些过往教训看，大略也只有三种状况。 大量锁期待线程不够用死锁有了这种先入为主的思维，那就上windbg说事呗。 二： windbg 剖析1. 有大量锁期待吗？要想看是否锁期待，老规矩，看一下 同步块表。 0:000> !syncblkIndex SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner-----------------------------Total 1673CCW 3RCW 4ComClassFactory 0Free 397扑了个空，啥也没有，那就暴力看看所有的线程栈吧。 不看还好，一看吓一跳，有339个线程卡在了 System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object) 处，不过转念一想，就算有339个线程卡在这里，真的会导致程序hangon吗？ 也不肯定，毕竟我看过有1000+的线程也不会卡死，只不过cpu爆高而已，接下来持续研判一下是不是线程不够用导致，能够从 线程池工作队列 下面动手。 2. 探索线程池队列能够用 !tp 命令查看。 0:000> !tpCPU utilization: 10%Worker Thread: Total: 328 Running: 328 Idle: 0 MaxLimit: 32767 MinLimit: 4Work Request in Queue: 74 Unknown Function: 00007ffe91cc17d0 Context: 000001938b5d8d98 Unknown Function: 00007ffe91cc17d0 Context: 000001938b540238 Unknown Function: 00007ffe91cc17d0 Context: 000001938b5eec08 ... Unknown Function: 00007ffe91cc17d0 Context: 0000019390552948 Unknown Function: 00007ffe91cc17d0 Context: 0000019390562398 Unknown Function: 00007ffe91cc17d0 Context: 0000019390555b30--------------------------------------Number of Timers: 0--------------------------------------Completion Port Thread:Total: 5 Free: 4 MaxFree: 8 CurrentLimit: 4 MaxLimit: 1000 MinLimit: 4从输入信息看，线程池中328个线程全部打满，工作队列中还有74位客人在期待，综合这两点信息就曾经很分明了，本次hangon是因为大量的客人到来超出了线程池的接待能力所致。 ...

尽管Microsoft Build才刚过来不久，但咱们在这里会持续分享咱们在.NET多平台应用程序 UI (.NET MAUI) 的继续停顿。在此版本中，咱们启用了动画和视图转换，实现了多个 UI 组件的移植，并对单个我的项目模板进行了改良。咱们还公布了第一批涵盖 .NET MAUI 介绍和根底方面的预览文档：https://docs.microsoft.com/en-us/dotnet/maui/。 动画在 .NET MAUI 中有几种执行动画的办法，其中最简略的办法是应用视图扩大办法，例如 FadeTo、RotateTo、ScaleTo、TranslateTo 等。在以下示例中，我应用新的 HandlerAttached 事件获取对每个绑定到布局的视图的援用（请参阅可绑定布局）： <DataTemplate x:Key="FavouriteTemplate"> <Frame AttachedHandler="OnAttached" Opacity="0"> ...</Frame><FlexLayoutBindableLayout.ItemTemplate="{StaticResource FavouriteTemplate}"BindableLayout.ItemsSource="{Binding Favorites}" >...</FlexLayout>当页面呈现时，我会以稍微交织的形式对视图进行动画解决，以创立丑陋的级联成果。 public partial class FavoritesPage : ContentPage{ List<Frame> tiles = new List<Frame>();void OnAttached(object sender, EventArgs e){ Frame f = (Frame)sender;tiles.Add(f);}protected override async void OnAppearing(){base.OnAppearing();await Task.Delay(300);TransitionIn();}async void TransitionIn(){foreach (var item in tiles){item.FadeTo(1, 800);await Task.Delay(50); }} }如需更残缺的视图动画编排，请查看自定义动画文档，该文档演示了增加多个能够并行运行的子动画。您能够从 GitHub 上的 WeatherTwentyOne 我的项目查看和运行此示例的源代码。 用户界面组件在此版本中，几个控件当初已将所有属性和事件从 Xamarin.Forms 的渲染器体系结构移植到处理程序，包含 ActivityIndicator、CheckBox、Image 和 Stepper。 在之前的预览版中，您须要查看是否移植了控件并从兼容包中为不可用的渲染器注册渲染器。 在 .NET MAUI Preview 5 中，咱们通过更新 UseMauiApp 扩大（请参阅 Startup wiki）为您连贯所有控件，无论它们是基于处理程序还是渲染器，使这变得更加容易。 ...

咱们很快乐公布 .NET 6 Preview 4。咱们当初大概实现了 .NET 6 公布的一半。当初是一个很好的机会，能够再次查看.NET6的残缺范畴。许多性能都靠近最终模式，而其余性能将很快推出，因为公布的根底构建块曾经就绪。预览版 4 为在 11 月交付最终的 .NET 6 构建奠定了松软的根底，并提供了残缺的性能和体验。如果您还没有在您的环境中尝试过 .NET 6，那么您当初能够用拉。 说到最终版本，咱们当初有一个日期了！ 预计在11 月 9 日至 11 日的.NET Conf 2021。咱们将在 9 日公布 .NET 6，其中蕴含许多深刻的演讲和演示，告诉您无关 .NET 6 的所有信息。 您能够下载实用于 Linux、macOS 和 Windows 的 .NET 6 预览版4。 安装程序和二进制文件容器镜像Linux 软件包发行阐明已知的问题GitHub 问题跟踪无关 Web 和数据拜访计划的新增性能的更多详细信息，请参阅 ASP.NET Core和 EF Core帖子。 还有新的 .NET MAUI帖子形容了新的客户端应用程序体验，还有一个热重载帖子形容了进步开发人员生产力的新办法。 .NET 6 曾经过 Visual Studio 16.11 和 Visual Studio for Mac 8.9 的测试。 如果您想在Visual Studio 中试用 .NET 6，咱们建议您应用这些版本。 ...

本文由葡萄城技术团队翻译并首发转载请注明出处：葡萄城官网，葡萄城为开发者提供业余的开发工具、解决方案和服务，赋能开发者。咱们很快乐公布.NET6预览的第6版，本次预览是倒数第二次预览了。在本次预览公布之后到最初一次预览之前，咱们会进入RC期，将会有两个RCs。这个版本自身绝对内容较少，而Preview7的内容会更多。在所有预览公布完结后，咱们将继续对问题进行修复，直到11月公布最终版本。请大家一起期待.NET的新版本。 .NET 6 Preview 6下载地址，依据各位的须要下载Linux, ,macOS, and Windows不同版本。 安装程序和二进制文件Linux packages发行阐明API差别已知问题GitHub问题跟踪器请参阅ASP.NET Core、EF Core和.NET MAUI文章，以理解无关web、数据拜访和客户端场景的新性能的更多详细信息。   从.NET 6 Preview 6开始，咱们曾经测试并反对Visual Studio 2022 Preview 2。Visual Studio 2022能够应用专门为.NET 6开发的Visual Studio工具，如.NET MAUI中的开发、C应用程序的热从新加载、WebForms的新Web Live预览，以及IDE体验中的其余性能改良。.net6也曾经用visualstudioformac8.9进行了测试。   查看.NET新个性探讨。 x64仿真更新咱们曾经实现了增加对Apple Silicon for macOS和Arm64 for Windows的反对。剩下的就是反对macOS、Apple Silicon和Windows Arm64上的x64仿真。   须要做以下两点实现： 装置并行应用.NET CLI实现一流体系结构指标，以便在所有场景中启用本机体系结构SDK。然而目前不不便的一点是，在并行安装程序可用之前（在之后的.NET6中），您须要装置所有x64版本或所有Arm64版本。如果要进行切换，须要卸载/删除Arm64计算机上的所有.NET版本。 工具：.NET SDK可选工作负载的改良咱们增加了三个新的工作负载命令，以实现更好的发现和治理。   l  dotnet workload search-列出可装置的工作负载 l  dotnet工作负载卸载-如果不再须要工作负载，请删除指定的工作负载。也是节俭空间的好抉择 l  dotnet工作负载修复-重新安装以前装置的所有工作负载   如果因为网络连接不好导致装置失败，就能够解决这个问题。   可选工作负载由多个工作负载包组成，所以会呈现局部负载包装置胜利，局部装置失败。 在以前的预览中，咱们增加了以下命令： dotnet workload install-装置工作负载dotnet workload list-列出已装置的工作负载dotnet workload update-更新已装置的工作负载库：对System.DirectoryServices.Protocols的TLS反对已为Linux和macOS的System.DirectoryServices.Protocols启用TLS反对。它曾经为Windows启用。NET用户当初能够享受与LDAP服务器的平安通信。 归功于@iinuwa。 工具：Crossgen2取代crossgen已为所有现有的crossgen计划启用了Crossgen2。在这个里程碑中，咱们还从SDK中删除了（旧的）crossgen，旧crossgem不可再拜访，无奈应用。   Crossgen（1和2）反对将IL预编译为本机代码作为公布步骤。预编译对启动的改良有很大帮忙。Crossgen2是一个从头开始的实现，曾经被证实是代码生成翻新的高级平台。例如，crossgen2能够为比crossgen1更宽泛的IL模式集生成代码。 ...

明天，咱们很快乐的向您介绍 Visual Studio 2019 版本 16.11（预览版 1）和 .NET 6 中的 dotnet watch 命令行工具（预览版 4）中的 .NET 热重载体验的可用性。在本博文，咱们心愿借此机会向您介绍什么是 .NET 热重载、如何开始应用此性能、咱们对将来打算改良的愿景是什么，以及明确以后反对的编辑类型和语言。 什么是 .NET 热重载？借助热重载，您当初能够在利用程序运行时批改应用程序托管的源代码，而无需手动暂停或点击断点。只需在利用运行时进行受反对的更改，在咱们全新的 Visual Studio 体验中，应用“利用代码更改”按钮即可利用您的编辑。 热重载实用于您现有和行将推出的许多我的项目类型，例如 WPF、Windows 窗体、.NET MAUI 预览、ASP.NET Core 应用程序后盾代码、控制台应用程序、WinUI 3（须要托管调试器）等等。这种反对十分宽泛，具备应用任何由 .NET Framework 或 CoreCLR 运行时提供反对的我的项目的外围教训。 应用 热重载，咱们的指标是无论您喜爱以何种形式启动应用程序，都能够提供这种体验。在明天的版本中，您当初能够通过齐全集成的 Visual Studio 调试器体验或 dotnet watch 命令行工具来应用这种体验，更多选项将在当前的版本中提供。 入门首先，您能够抉择应用 Visual Studio 的最新预览版或咱们的 .NET 6 Preview 4，阐明如下。 Visual Studio:要在应用调试器时在 Visual Studio 中尝试热重载： 下载并装置 Visual Studio 2019 版本 16.11 预览版 1关上反对的我的项目类型，例如 WPF 利用通过 F5 连贯调试器启动应用程序（确保在调试器设置/调试启动配置文件中禁用“启用本机代码调试”）关上蕴含一些代码的 C# 代码文件，这些代码能够通过正在运行的应用程序用户界面（例如：按钮的后盾代码或 ViewModel 的命令）或通过计时器每隔一段时间触发的代码从新执行并更改代码应用 Visual Studio 工具栏中的新利用代码更改 (ALT-F10) 按钮（在“持续”按钮旁边）利用代码更改。请留神，应用 Visual Studio 时不须要保留文件，这使您能够灵便地疾速更改代码并继续前进。如果您所做的更改失去反对，您的应用程序当初将在应用新逻辑运行时进行修补，并且您应该在下一次通过您的操作或相似触发代码的计时器从新执行更新的代码时看到应用程序行为中的更改。 ...

Visual Studio 2019 v16.10有什么新性能?咱们很快乐地发表Visual Studio 2019 v16.10 GA 和 v16.11 preview 1公布。此版本使咱们的主题“开发者生产力和便利性”广泛实用于 Visual Studio 用户！咱们增加了c++ 20个性、优化的Git集成、剖析工具，以及许多进步开发效率的个性。 下载最新的Visual Studio版本以尝试16.10中的新个性。判若两人，咱们心愿您通过咱们的开发者社区提供反馈和互动。装置visual studio 2019 v16.10 C++咱们的编译器和 STL 当初性能齐备，实用于最新可用的C++20 规范！16.10带来了一些备受期待的个性：日历、时区和 <format>。这些个性都能够在/std:c++latest开关下应用。不过/std:c++20开关还不可用，因为一些个性预期将在缺点报告(ISO c++20 bug修复)中以ABI不兼容的形式进行修改(更多细节请参阅Microsoft/STL Issue #1814)。<format> 是一种新的基于 fmtlib 的文本格式工具。 它为 iostreams 和 printf 系列提供了一种疾速且平安的代替计划： auto version = 20;std::format(“STL is now C++{} feature-complete!”, version);日历和时区是对现有<chrono>工具的扩大。它们提供了一种类型平安和时区感知的形式，来示意和操控日期和工夫。 std::chrono::year_month_day world_bee_day = May/20d/2021ystd::format("Buzz buzz on %F!”, world_bee_day);此外，咱们还改良了模块、范畴和概念的智能感知体验。“转到定义”既实用于模块自身，也实用于从模块中导入的定义。对于编译器来说，编译器进入范畴是出了名的艰难，然而智能感知当初能够为你做这件事。另外，定义的概念名称会主动补全。 当初，除了x64之外， x86和ARM64也反对 LLVM OpenMP 运行时。通过/openmp:llvm开关来指向它。如果你想应用c++ 20-style的协程，但指标是c++ 11或c++ 14，你当初能够应用/await:strict开关来取得想要的行为。咱们改良了协程的调试和可视化。特地是，std::coroutine_handle的可视化当初显示了原始的协程函数名和签名以及以后挂终点。 如果你正在应用咱们的CMake反对，那么你当初能够应用CMakePresets来指定配置，而不是应用cmakessetting .json。这种格局在Visual Studio、Visual Studio Code和任何其余反对这种新规范的工具之间是统一的。 ...

作者：陈超超 Ant Design Blazor我的项目贡献者，领有十多年从业教训，长期基于.Net技术栈进行架构与开发产品的工作，现就职于正泰团体。 邮箱：timchen@live.com欢送各位读者有任何问题分割我，咱们共同进步。背景目前Blazor中可用的图表组件库次要有以下几个 ant-design-blazor/ant-design-charts-blazor 基于G2Plotmariusmuntean/ChartJs.Blazor 基于ChartJsblazor-cn/Blazor.ECharts 基于EChartsant-design-charts-blazor是我主导实现的，相干应用教程可参阅《进击吧！Blazor！》系列入门教程 第一章 7.图表然而这些图表库无不例外的采纳的JS库进行二次分装，根本实现形式雷同，我以ant-design-charts-blazor举例 大抵逻辑如下 首先通过IJSRuntime接口与本人开发的own.js进行交互own.js中对图表库的api做了简略封装，次要目标是缩小.razor与G2Plot的交互，毕竟IJSRuntime接口调用js对象没有js之间间接互相调用不便G2Plot会在Canvas中绘制出图表图表中的一些事件通过own.js进行捕获后通过IJSRuntime反馈给.razorant-design-charts-blazor的技术实现形式可详见我之前的文章用Blazor技术封装G2Plot实现Charts组件看了上述内容，咱们思考一下，Blazor技术将C#带到了前端，咱们却持续应用着JS的图表库，正当吗？显著不合理，所以咱们应该去创立一个基于Blazor技术构建的图表库代替下面的JS库。 到这里还有一个小问题，就是Canvas提供的接口都是面向JS的，那么咱们须要另外一个绘图技术，需兼顾性能和性能，其实不必选，SVG，就是你了。 可缩放矢量图形（Scalable Vector Graphics，SVG），是一种用于形容二维的矢量图形，基于 XML 的标记语言。作为一个基于文本的凋谢网络规范，SVG可能优雅而简洁地渲染不同大小的图形，并和CSS，DOM，JavaScript和SMIL等其余网络规范无缝连接。BlazorChartsBlazorCharts是我主导的开源我的项目，指标是创立一个基于Blazor技术，应用简略，性能绝对丰盛的图表库。 我的项目地址：https://github.com/TimChen44/blazor-charts 我的项目信息首先，确定一个图标，俗话说图标确定后我的项目就实现了一半，以自己的能力，只能将图表和@合并，设计出“缝合怪”作为我的图标 接着，再确定咱们组件的一些根本理念，我今后的设计尽我所能满足这些理念。 应用简略组件库是拿来用的，所以应用形式要简略，应用办法要合乎惯例逻辑，争取应用时最大可能的缩小对文档的依赖。性能实用实现一堆极少场景才会应用的图表，不如集中精力做好用的最多的那些图表。实现一堆极少场景才会应用的性能，不如集中精力做好用的最多的那些性能。信息直观应用图表的外围目标是解决表格数据显示不直观的问题，所以不管性能、布局、色彩、动画都是为了这个服务。实现形式介绍首先咱们看一下图表蕴含的根本元素 基于这个构造，上面是我我的项目的类图，通过一些形象，将图表的一些元素进行了演绎。 图表中每一个元素的大小地位变动都会影响到其余元素，所以地位和布局的确定存在一个先后关系，程序如下 graph LR图表 --> 题目题目 --> 图例图例 --> 坐标轴坐标轴 --> X轴宽度坐标轴 --> Y轴高度X轴宽度 --> Y轴宽度Y轴高度 --> X轴高度Y轴宽度 --> 系列组X轴高度 --> 系列组系列组 --> 系列A系列组 --> 系列B系列组 --> 系列C图表成果上面是一个最简略的图表示例 所需的配置 <BcChart Height="600" Width="800" Data="DemoData.Githubs" CategoryField="x=>x.Year.ToString()"> <BcTitle Title="图表示例" TData="Github"></BcTitle> <BcAxesY TData="Github" GridLineMajor="true" GridLineMinor="true"></BcAxesY> <BcLegend TData="Github" BorderWidth="1" Position="LegendPosition.Bottom"></BcLegend> <BcColumnSeries TData="Github" ValueFunc="x=>x.Sum(y=>y.View)" GroupName="View"></BcColumnSeries> <BcColumnSeries TData="Github" ValueFunc="x=>x.Sum(y=>y.Start)" GroupName="Start"></BcColumnSeries> <BcLineSeries TData="Github" ValueFunc="x=>x.Sum(y=>y.Fork)" GroupName="Fork" IsSecondaryAxis="true"></BcLineSeries></BcChart>所需的数据 static class DemoData{ public static List<Github> Githubs = new List<Github>() { new Github(){Year=2017,View =2500,Start=800,Fork=400}, new Github(){Year=2018,View =2200,Start=900,Fork=800}, new Github(){Year=2019,View =2800,Start=1100,Fork=700}, new Github(){Year=2020,View =2600,Start=1400,Fork=900}, };}更多内容请观看《Balzor Day 2021》的视频https://www.bilibili.com/vide... ...

一：背景1. 讲故事前几天有位敌人加wx说他的程序遭逢了内存暴涨，求助如何剖析？ 和这位敌人聊下来，这个dump也是取自一个HIS零碎，如敌人所说我这真的是和医院杠上了，这样也好，给本人攒点资源，好了，不扯了，上windbg谈话。 二： windbg 剖析1. 托管还是非托管？既然是内存暴涨，那就看看以后过程的 commit 内存有多大？ 0:000> !address -summary--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_FREE 174 7ffe`baac0000 ( 127.995 TB) 100.00%MEM_COMMIT 1153 1`33bd3000 ( 4.808 GB) 94.59% 0.00%MEM_RESERVE 221 0`1195d000 ( 281.363 MB) 5.41% 0.00%能够看出大略占了 4.8G,接下来再看看托管堆内存。 0:000> !eeheap -gcNumber of GC Heaps: 1generation 0 starts at 0x00000207a4fc48c8generation 1 starts at 0x00000207a3dc3138generation 2 starts at 0x0000020697fc1000ephemeral segment allocation context: none------------------------------GC Heap Size: Size: 0x1241b3858 (4900730968) bytes.从最初一行能够看出托管堆占用 4900730968/1024/1024/1024=4.5G，两个指标一比对，原来是托管内存出问题了，这下好办了。。。 ...

一：背景1. 讲故事曾经间断写了几篇对于内存暴涨的实在案例，有点麻痹了，这篇换个口味，分享一个 CPU爆高 的案例,前段时间有位敌人在 wx 上找到我，说他的一个老我的项目常常收到 CPU > 90% 的告警信息，挺难堪的。 既然找到我，那就用 windbg 剖析呗，还能怎么办。 二： windbg 剖析1. 勘探现场既然说 CPU > 90%，那我就来验证一下是否真的如此？ 0:359> !tpCPU utilization: 100%Worker Thread: Total: 514 Running: 514 Idle: 0 MaxLimit: 2400 MinLimit: 32Work Request in Queue: 1 Unknown Function: 00007ff874d623fc Context: 0000003261e06e40--------------------------------------Number of Timers: 2--------------------------------------Completion Port Thread:Total: 2 Free: 2 MaxFree: 48 CurrentLimit: 2 MaxLimit: 2400 MinLimit: 32从卦象看，真壮观，CPU间接被打满，线程池里 514 个线程也正在满负荷奔跑，那到底都奔跑个啥呢？ 首先我得狐疑一下这些线程是不是被什么锁给定住了。 2. 查看同步块表察看锁状况，优先查看同步块表，毕竟大家都喜爱用 lock 玩多线程同步，能够用 !syncblk 命令查看。 ...

在咱们最近让咱们一起学习.NET的微服务专场流动中，咱们收到了一些很好的问题。咱们在现场曾经答复很多问题，但咱们想持续答复一些在会议中呈现的最热门的问题。如果你错过了现场直播，不要放心，因为你能够按需观看。 https://www.bilibili.com/vide... 当咱们扩大这些服务时，咱们如何扩大与这些服务相干的数据库?有一些定义良好的模式和最佳实际能够进步性能和扩大数据库。想要理解如何将数据划分为分区，以进步可伸缩性、缩小和优化性能, 请参阅程度、垂直和功能性数据分区。想要深入研究微服务的伸缩性，分布式数据，为什么每个微服务都有数据库，在关系数据库和NoSQL数据库之间进行抉择，请参考咱们对于为Azure构建云原生.net应用程序的领导或下载收费的电子书。 咱们是否须要为每个微服务应用一个新的数据库，或者微服务能够共享雷同的数据库实例?团队应用微服务的自主性是构建云原生利用的一个重要益处。为了可能使团队可能灵便地在生产中推出更新、安全补丁和bug修复，而不会毁坏其余微服务, 最好应用独立的数据库实例。原生云利用架构的灵感来自于驰名的12因素应用程序方法论。其中一个因素“反对服务”指出，数据存储、缓存、音讯代理等辅助资源应该通过一个可寻址URL公开。云提供商提供了各种各样丰盛的托管反对服务。咱们倡议查看云中可用的数据库选项，而不是本人领有和保护数据库。 单个Web API能与微服务通信吗?是的。如果微服务的端点在基础设施中是可达到的，或者应用公共端点平安地拜访，那么单片应用程序能够与微服务进行通信。微服务及其数据能够通过其端点进行同步生产，或也能够通过消息传递(如事件总线)进行异步生产。作为现代化技术的一部分，咱们举荐有助于渐进地迁徙旧零碎的扼杀模式。作为解决方案的一部分，您须要创立一个阻止申请的façade。façade将这些申请路由到旧应用程序或新服务。想要理解更多对于微服务通信和现代化技术的信息，请参阅.net体系结构指南。 如果微服务是涣散耦合和独立部署的，它们如何互相通信?如何在微服务之间同步数据?这是个很好的问题。在《为Azure构建云原生.net应用程序》一书的两个章节中具体解释了这个问题。这些链接会对你有所帮忙: 原生云通信模式或下载收费电子书。在分布式应用中治理数据。你也能够下载对于微服务架构指南的收费电子书，其中涵盖了一些模式，如DDD、CQRS、事件源等。微服务须要应用容器吗?没有必要的。然而，应用容器也有它的益处。微服务，通常称为微服务体系结构，是设计领导和最佳实际。它帮忙您将应用程序合成为由特定业务边界定义的多个较小的服务，这些服务由较小的团队独立治理。容器将应用程序及其配置和依赖项组合成一个独自的、独立的可部署单元。容器非常适合绑定和部署独立的微服务。您能够通过编写第一个微服务端点并将其容器化来理解其益处。 更多的microservices资源您是否正在寻找更多用于.net开发的微服务和本地云资源?请继续关注微软的blog和官网文档。有任何问题，欢送来Microsoft Q&A 论坛发问:https://docs.microsoft.com/en...

一：背景1. 讲故事最近几天接到了几个crash的求助，可能这几个敌人没玩过怎么去生成dump，只能手把手教，感觉也不是一个方法，所以有必要总结一下，后续再有敌人征询的话，我就能够把这篇文章丢过来了，好了，我大略总结了上面三种形式： procdump -eprocdump -> AEDebugWindows Error Reporting老读者应该晓得，我始终都推崇 procdump 去搞定这些事件，毕竟它是一款可跨平台抓取的弱小乖巧工具。 二: 实现可测试案例从 dump 样本来看，web类的程序是最多的，所以这里我就以 Asp.NET MVC 5 作为案例，在 RouteConfig 类中我应用一个Timer一直的抛出异样，目标就是把 w3wp 过程给弄挂掉，参考代码如下： public class RouteConfig { public static Timer timer; public static void RegisterRoutes(RouteCollection routes) { timer = new Timer(new TimerCallback(m => { var r = 10 / Convert.ToInt32("0"); }), null, 60000, 5000); routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); routes.MapRoute( name: "Default", url: "{controller}/{action}/{id}", defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional } ); } }对了，必定有敌人问：为什么不在 Action 中抛异样，这是因为 Http管道 会把这种异样包装成 http 500，所以就达不到 crash 的成果了。 ...

一：背景1. 讲故事上周四有位敌人加wx征询他的程序内存存在肯定水平的透露，并且无奈被GC回收，最终机器内存耗尽，很难堪。 沟通下来，这位敌人能力还是很不错的，也曾经做了初步的dump剖析，发现了托管堆上有 10w+ 的 byte[] 数组，并占用了大略 1.1G 的内存，在抽取几个 byte[] 的 gcroot 后发现没有援用，接下来就排查不上来了，尽管晓得问题可能在 byte[]，但苦于找不到证据。 那既然这么信赖的找到我，我得要做一个绝对全面的输入报告，不能辜负大家的信赖哈，还是老规矩，上 windbg 谈话。 二： windbg 剖析1. 排查透露源看过我文章的老读者应该晓得，排查这种内存泄露的问题，首先要二分法找出到底是托管还是非托管出的问题，不便后续采取相应的应答措施。 接下来应用 !address -summary 看一下过程的提交内存。 ||2:2:080> !address -summary--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_PRIVATE 573 1`5c191000 ( 5.439 GB) 95.19% 0.00%MEM_IMAGE 1115 0`0becf000 ( 190.809 MB) 3.26% 0.00%MEM_MAPPED 44 0`05a62000 ( 90.383 MB) 1.54% 0.00%--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_FREE 201 7ffe`9252e000 ( 127.994 TB) 100.00%MEM_COMMIT 1477 0`d439f000 ( 3.316 GB) 58.04% 0.00%MEM_RESERVE 255 0`99723000 ( 2.398 GB) 41.96% 0.00%从卦象的 MEM_COMMIT 指标看：以后只有 3.3G 的内存占用，说实话，我个别都倡议 5G+ 是做内存透露剖析的最低门槛，毕竟内存越大，越容易剖析，接下来看一下托管堆的内存占用。 ...

一：背景1. 讲故事前天那位 his 老哥又来找我了，上次因为CPU爆高的问题我给解决了，看样子对我挺信赖的，这次另一个程序又遇到内存透露，心愿我帮忙诊断下。 其实这位老哥技术还是很不错的，他既然能给我dump，那真的是遇到很辣手的疑难杂症了，我得做好心理准备，沟通下来大略就是程序的内存会迟缓收缩，直到自毁，问题就是这么一个问题，接下来祭出我的看家工具 windbg。 二： windbg 剖析1. 到底哪里透露了？我在之前很多篇文章中都说过，遇到这种内存透露，首先就要排查到底是 托管堆 还是 非托管堆 的问题 ？如果是后者，大多数状况只能举手投降，因为这外面水太深了。。。 别看那些案例用 AllocHGlobal 办法调配非托管内存，而后用 !heap 去找的小儿科，现实情况比这种要简单的多。。。 接下来先用 !address -summary 看一下以后过程的提交内存。 0:000> !address -summary--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalFree 345 7dfd`ca3ca000 ( 125.991 TB) 98.43%<unknown> 37399 201`54dbf000 ( 2.005 TB) 99.83% 1.57%Heap 29887 0`d179b000 ( 3.273 GB) 0.16% 0.00%Image 1312 0`0861b000 ( 134.105 MB) 0.01% 0.00%Stack 228 0`06e40000 ( 110.250 MB) 0.01% 0.00%Other 10 0`001d8000 ( 1.844 MB) 0.00% 0.00%TEB 76 0`00098000 ( 608.000 kB) 0.00% 0.00%PEB 1 0`00001000 ( 4.000 kB) 0.00% 0.00%--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_MAPPED 352 200`00a40000 ( 2.000 TB) 99.57% 1.56%MEM_PRIVATE 67249 2`2cbcb000 ( 8.699 GB) 0.42% 0.01%MEM_IMAGE 1312 0`0861b000 ( 134.105 MB) 0.01% 0.00%--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_FREE 345 7dfd`ca3ca000 ( 125.991 TB) 98.43%MEM_RESERVE 11805 200`22ae8000 ( 2.001 TB) 99.60% 1.56%MEM_COMMIT 57108 2`1313e000 ( 8.298 GB) 0.40% 0.01%从卦象上看， 过程提交内存 MEM_COMMIT = 8.2G, 而后咱们看下托管堆大小，应用 !eeheap -gc 命令。 ...

一：背景1. 讲故事前几天有位敌人wx求助，它的程序CPU常常飙满，没找到起因，心愿帮忙看一下。 这些天间断接到几个cpu爆高的dump，都看烦了，心愿前面再来几个其余方面的dump，从沟通上看，这位敌人体现的好惨，可能理论更惨，那既然找到我了，我就尽最大能力帮他找到幕后真凶，话不多说，上 windbg。 二： windbg 剖析1. 查看托管线程因为线程都是靠cpu养着，所以从线程上动手也是一个很好的思路，要想查看程序的所有托管线程，能够应用 !t 命令。 0:000> !tThreadCount: 38UnstartedThread: 0BackgroundThread: 34PendingThread: 0DeadThread: 3Hosted Runtime: no Lock ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception 0 1 105c 000000000067f600 2a020 Preemptive 0000000000000000:0000000000000000 0000000000671ec0 0 MTA 2 2 13d0 00000000192c4f40 2b220 Preemptive 0000000000000000:0000000000000000 0000000000671ec0 0 MTA (Finalizer) ...XXXX 15 0 000000001bc64970 8039820 Preemptive 0000000000000000:0000000000000000 0000000000671ec0 0 MTA (Threadpool Completion Port) 24 23 1380 000000001bc660e0 8029220 Preemptive 0000000000000000:0000000000000000 0000000000671ec0 0 MTA (Threadpool Completion Port) XXXX 53 0 000000001bc63200 8039820 Preemptive 0000000000000000:0000000000000000 0000000000671ec0 0 MTA (Threadpool Completion Port) XXXX 27 10dc 000000001bd0dbf0 1029220 Preemptive 0000000002CB40F8:0000000002CB4108 0000000000671ec0 1 MTA (GC) (Threadpool Worker) 在卦象上看：程序有38个线程，死了3个，我去，有一个亮点，最初一行呈现了一个相熟的 MTA (GC) 字样，这什么意思呢？ 这示意以后线程触发了GC，但奇怪的是，这个触发GC的线程死了，你必定要问怎么看进去的，看行头的 XXXX，先不论了，死马当活马医，调出线程的所有托管和非托管栈，看看有没有 WaitUntilGCComplete 和 try_allocate_more_space 字样。 ...

一：背景1. 讲故事前几天有位敌人wx求助，它的程序内存常常飙升，cpu 偶然飙升，没找到起因，心愿帮忙看一下。 惋惜发过来的 dump 只有区区2G，能在这外面找到内存溢出那真有两把刷子。。。，所以我还是心愿他的程序内存涨到 5G+ 的时候再给我看看，既然内存看不了，那就看看这个偶然飙升的CPU是个啥状况？老办法，上windbg谈话。 二： windbg 剖析1. CPU 到底是多少要想查看这个快照生成时机器的cpu使用率，能够应用 !tp 命令。 0:033> !tpCPU utilization: 93%Worker Thread: Total: 800 Running: 800 Idle: 0 MaxLimit: 800 MinLimit: 320Work Request in Queue: 3203 Unknown Function: 000007fefb551500 Context: 000000002a198480 Unknown Function: 000007fefb551500 Context: 0000000028a70780 Unknown Function: 000007fefb551500 Context: 000000002a182610 Unknown Function: 000007fefb551500 Context: 00000000262a2700 ...本认为一个简略的命令，后果屏幕上呼啦啦的一堆。。。 有点意外，从下面的卦象看：以后CPU利用率是 93%，没故障，的确是CPU飙升，比拟诧异的是，线程池下限800个线程全副被打满，太悲壮了。。。可更悲壮的是线程池队列中还有 3203 个待处理的工作，能够猜想程序不仅高CPU，还有挂死景象。。。 接下来的问题是：这800个壮士到底怎么啦，程序当初正是用人之际，要想找出答案，还是依照我的惯性思维，查看同步块表。 2. 线程同步块表要想查看同步块表，能够应用 !synblk 命令。 0:033> !syncblkIndex SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner 188 0000000010defc28 1 1 000000001e8fb400 9f4 715 00000003ff1e3d80 System.Web.HttpApplicationStateLock126159 000000001e424e28 1 1 0000000023425e00 1f14 695 0000000301210038 ASP.global_asax126173 00000000281acaf8 1 1 0000000024b8ea70 24ec 785 00000000ff8c5e10 ASP.global_asax126289 00000000247a4068 1 1 0000000027ee93c0 808 413 0000000306aca288 ASP.global_asax126368 0000000027180dd8 1 1 0000000028005cb0 1e7c 650 00000002008d6280 ASP.global_asax126489 0000000027211dd8 1 1 0000000026862420 ec4 220 000000030611a290 ASP.global_asax126788 00000000247924b8 1 1 0000000021871ff0 2784 529 00000004039901a8 ASP.global_asax126843 00000000285b8d28 1 1 000000001cbd6710 2170 456 00000004007ec748 ASP.global_asax126934 0000000021b212b8 1 1 0000000026ca7590 16cc 472 000000030090e810 ASP.global_asax127251 0000000024769188 1 1 000000002831eaf0 2b68 648 0000000207051038 ASP.global_asax...-----------------------------Total 141781CCW 2RCW 4ComClassFactory 0Free 140270我去，又是呼啦啦的一堆，从下面的卦象能够看出两点信息： ...

一：背景1. 讲故事前几天有位敌人加 wx 埋怨他的程序在高峰期总是莫名其妙的cpu爆高，求助如何剖析？ 和这位敌人沟通下来，据说这问题困扰了他们几年，还请了微软的工程师过去解决，无疾而终，应该还是没找对微软的大佬。。。 对于程序CPU爆高的问题，老读者应该晓得我都写了好几篇了，基本上归为两类： GC 触发大量 lock 锁少部分就是各种莫名其妙的问题了，无奈一一列举 ，既然敌人找到我了，我得想方法给他解决，话不多聊，上 windbg。 二： windbg 剖析1. 查看同步块表遇到这种问题，首查 同步块表 曾经是我的惯性思维了，命令很简略 !syncblk 。 0:000> !syncblkIndex SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner-----------------------------Total 20779CCW 16RCW 21ComClassFactory 0Free 16490我去，扑了一个空，同步块表中啥也没有。。。 既然和锁没关系，那就看看线程吧，毕竟线程就是靠 CPU 养着的。 2. 查看线程要想查看零碎中的 托管线程 ，能够应用 !t 命令, 线程比拟多，略微简化一下。 0:000> !tThreadCount: 135UnstartedThread: 0BackgroundThread: 132PendingThread: 0DeadThread: 1Hosted Runtime: no Lock ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception 34 1 25d4 000001ea28702130 28220 Preemptive 0000000000000000:0000000000000000 000001ea286ee080 0 Ukn 74 2 3ed0 000001ea286fa940 2b220 Preemptive 0000000000000000:0000000000000000 000001ea286ee080 0 MTA (Finalizer) 76 3 4a70 000001f4447d7810 102a220 Preemptive 0000000000000000:0000000000000000 000001ea286ee080 0 MTA (Threadpool Worker) 77 4 326c 000001f4447dbe60 21220 Preemptive 0000000000000000:0000000000000000 000001ea286ee080 0 Ukn 78 6 2dac 000001f4447d9750 1020220 Preemptive 0000000000000000:0000000000000000 000001ea286ee080 0 Ukn (Threadpool Worker) 79 7 1468 000001f444a2d6f0 21220 Preemptive 0000000000000000:0000000000000000 000001ea286ee080 1 Ukn (GC) 80 8 f0 000001f444a2cf20 21220 Preemptive 0000000000000000:0000000000000000 000001ea286ee080 0 Ukn 81 9 3118 000001f444a2f630 21220 Preemptive 0000000000000000:0000000000000000 000001ea286ee080 0 Ukn 先卖个关子，可有敌人看出这些线程有什么同样？？？ 对，线程 79 的最初一列有一个 Ukn (GC) 标记，我想你必定好奇，这阐明什么？ 因为底层GC的模式有些变更，但不管怎么说，它在肯定水平上通知你，你的程序触发了GC，为了进一步验证，能够用 !t -special 看下 79 号线程到底属于什么类别以及更加具体的信息。 ...

本文首发于码友网--《.NET 5/.NET Core应用程序中应用音讯队列中间件RabbitMQ示例教程》 前言在现在的互联网时代，音讯队列中间件未然成为了分布式系统中重要的组件，它能够解决利用耦合，异步音讯，流量削峰等利用场景。借助音讯队列，咱们能够实现架构的高可用、高性能、可伸缩等个性，是大型分布式系统架构中不可或缺的中间件。 目前比拟风行的音讯队列中间件次要有：RabbitMQ, NATS, Kafka, ZeroMQ, Amazon SQS, ServiceStack, Apache Pulsar, RocketMQ, ActiveMQ, IBM MQ等等。 本文次要为大家分享的是在.NET 5应用程序中应用消息中间件RabbitMQ的示例教程。 筹备工作在开始本文实战之前，请筹备以下环境： 消息中间件：RabbitMQ开发工具：Visual Studio 2019或VS Code或Rider笔者应用的开发工具是Rider 2021.1.2。 筹备解决方案和我的项目创立我的项目关上Rider，创立一个名为RabbitDemo的解决方案，再顺次创立三个基于.NET 5的我的项目，别离为：RabbitDemo.Shared, RabbitDemo.Send以及RabbitDemo.Receive。 RabbitDemo.Shared 我的项目次要用于寄存共用的RabbitMQ的连贯相干的类；RabbitDemo.Send 我的项目次要用于模仿生产者(发布者)；RabbitDemo.Receive 我的项目次要用于模仿消费者(订阅者)装置依赖包首先，在以上创立的三个我的项目中别离应用包管理工具或者命令行工具装置RabbitMQ.Client依赖包，如下： 编写RabbitDemo.Shared我的项目RabbitDemo.Shared我的项目次要用于寄存共用的RabbitMQ的连贯相干的类。这里咱们创立一个RabbitChannel类，而后在其中增加创立一些连贯RabbitMQ相干的办法，包含初始化RabbitMQ的连贯，敞开RabbitMQ连贯等，代码如下： using RabbitMQ.Client;namespace RabbitDemo.Shared{ public class RabbitChannel { public static IModel Channel; private static IConnection _connection; public static IConnection Connection => _connection; public static void Init() { _connection = new ConnectionFactory { HostName = "xxxxxx", // 你的RabbitMQ主机地址 UserName = "xxx", // RabbitMQ用户名 VirtualHost = "xxx", // RabbitMQ虚拟主机 Password = "xxxxxx" // RabbitMQ明码 }.CreateConnection(); Channel = _connection.CreateModel(); } public static void CloseConnection() { if (Channel != null) { Channel.Close(); Channel.Dispose(); } if (_connection != null) { _connection.Close(); _connection.Dispose(); } } }}编写音讯生产者在我的项目RabbitDemo.Send中，援用我的项目RabbitDemo.Shared，而后创立一个名为Send.cs类，并在其中编写生产者的代码，如下： ...

一：背景1. 讲故事前些天把 .NET 高级调试 方面的文章索引到 github 的过程中，发现了一个有意思的评论，详见 文章，截图如下： 大略就是说在 Winform 的主线程下执行 Task.Result 会造成死锁，我也看了图中的参考链接, Stephen 是相对的大佬，不过这篇文章对死锁的成因次要还是大段的文字灌输，没有真的让你眼见为实，那这篇我就从 windbg 的角度来给它分析下。 二： windbg 剖析1. 真的会死锁吗？看文章看截图貌似真的会死锁，当然我多年不玩 winform 了，也搞不清楚到底会不会，至多在 Console 中是不会的，得，先上一段测试代码。 public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void button1_Click(object sender, EventArgs e) { var jsonTask = GetJsonAsync("http://cnblogs.com").Result; textBox1.Text = jsonTask; } public async static Task<string> GetJsonAsync(string uri) { using (var client = new HttpClient()) { var jsonString = await client.GetStringAsync(uri); return jsonString; } } }代码非常简单，把程序跑起来，点一下 click，果然界面卡住了，有点不堪设想。 ...

一：背景1. 讲故事前几天有位敌人加wx求助说他的程序最近总是呈现内存溢出，很解体，如下图： 和这位敌人聊下来，发现他也是搞医疗的，哈哈，.NET 在医疗方面还是很有市场的，不过对于内存方面出的问题，我得先祷告一下千万不要是非托管。。。 废话不多说，上 windbg，看能不能先救个急。 二： windbg 剖析1. 找出异样对象如果内存溢出了，大家应该晓得 C# 会抛一个 OutOfMemoryException 异样，而且还会附加到那个执行线程上，所以先用 !t 命令调出以后的所有托管线程。 0:000> !tThreadCount: 17UnstartedThread: 0BackgroundThread: 12PendingThread: 0DeadThread: 4Hosted Runtime: no Lock ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception 0 1 16b0 007da908 26020 Preemptive 64EDD188:00000000 00823830 1 STA System.OutOfMemoryException 57b53d90 2 2 af8 007e9dc8 2b220 Preemptive 00000000:00000000 007d4838 0 MTA (Finalizer) 3 3 1d94 0081af28 21220 Preemptive 00000000:00000000 007d4838 0 Ukn 5 6 246c 0772b960 102a220 Preemptive 00000000:00000000 007d4838 0 MTA (Threadpool Worker) 8 47 277c 2eebf038 8029220 Preemptive 00000000:00000000 007d4838 0 MTA (Threadpool Completion Port) XXXX 41 0 2eebf580 1039820 Preemptive 00000000:00000000 007d4838 0 Ukn (Threadpool Worker)能够分明的看到，0号 线程果然带了一个 System.OutOfMemoryException，接下来用 !pe 查查这个异样的调用栈信息。 ...

咱们在.NET 6 Preview 3中交付了.NET多平台利用UI的挪动和桌面开发的最新进展。此版本增加了Windows平台和WinUI 3，改良了根本应用程序和启动构建器，增加了原生生命周期事件，并增加了更多UI控件和布局。咱们还为辅助性能引入了一些新的语义属性。当咱们对这些进行具体探讨时，咱们邀请您与咱们一起应用dotnet new创立新利用，并分享您的反馈。 反对Windows桌面Project Reunion 0.5已公布！当初，Windows退出了Android，iOS和macOS，成为您能够应用.NET MAUI达到的指标平台！您能够从Project Reunion装置阐明开始体验。在这个版本中，咱们创立了一个示例我的项目，您能够从Visual Studio 2019 16.10 Preview中开始摸索。 一旦有了用于Project Reunion的必要的.NET 6根底构建架构，咱们就会将Windows增加到咱们的单我的项目模板中。 入门因为咱们仍处于预览的晚期阶段，因而装置挪动和桌面开发所需的所有依赖项的过程还是依赖于手动操作。为了帮忙您和咱们本人，乔纳森·迪克（Jonathan Dick）整顿了一个有用的工具dotnet tool，它能够评估您的零碎并尽可能多地收集所需的组件。应用这个工具须要从命令行全局装置maui-check dotnet tool install -g Redth.Net.Maui.Check 源：https://github.com/Redth/dotn... 当初运行> maui-check并依照阐明进行操作。胜利之后，就能够创立您的第一个应用程序了： dotnet new maui -n HelloMaui 无关装置和入门的分步阐明，也能够参考：https://github.com/dotnet/maui/wiki/Getting-Started。 您的第一个应用程序.NET MAUI应用Microsoft.Extensions HostBuilder启动每个应用程序。这为应用程序开发人员和库保护人员提供了统一的模式，以便疾速开发应用程序。每个平台都有不同的起始点，然而您的应用程序入口统一位于Startup.cs。这里有个简略例子： public class Startup : IStartup { public void Configure(IAppHostBuilder appBuilder) { appBuilder .UseMauiApp(); } }在这里，您能够执行诸如注册字体和注册Xamarin.Forms渲染器或自定义渲染器兼容性的操作。这也是您引入您的App的中央，即实现Application并（至多）负责创立一个新的Window： public partial class App : Application { public override IWindow CreateWindow(IActivationState activationState) { return new MainWindow(); } } 为了出现您的内容，一个视图会被增加到MainWindow： ...

一：背景1. 讲故事这篇文章起源于 搬砖队大佬 的精彩文章 WinDBg定位asp.net mvc我的项目异样解体源码地位 ，写的十分好，不过美中不足的是通览全文之后，总感觉有那么一点不过瘾，就是没有把过后抛异样前的参数给找进去。。。这一篇我就试着补救这个遗憾。 为了可能让文章行云流水，我就依照本人的侦察思路吧，首先看一下现状：iis上的应用程序解体, catch 不到谬误，windows日志中只记录了一个 AccessViolationException 异样，如何剖析？ 说实话我也是第一次在托管语言 C# 中遇到这种异样，够奇葩，先看看 MSDN 上的解释。 好了，先不论奇葩不奇葩，反正有了一份 dump + AccessViolationException，还是能够挖一挖的，老规矩，上windbg谈话。 二： windbg 剖析1. 寻找异样的线程如果是在 异样解体 的时候抓的dump，一般来说这个异样会挂在这个执行线程上，不置信的话，能够看看dump。 0:0:037> !tThreadCount: 9UnstartedThread: 0BackgroundThread: 9PendingThread: 0DeadThread: 0Hosted Runtime: no Lock ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception 8 1 2188 019da830 28220 Preemptive 10C08398:00000000 01a02bd8 0 Ukn 29 2 36b8 025d7738 2b220 Preemptive 00000000:00000000 01a02bd8 0 MTA (Finalizer) 31 3 1c6c 0260b568 102a220 Preemptive 00000000:00000000 01a02bd8 0 MTA (Threadpool Worker) 32 4 315c 02616678 21220 Preemptive 00000000:00000000 01a02bd8 0 Ukn 34 6 31c0 026180e0 1020220 Preemptive 00000000:00000000 01a02bd8 0 Ukn (Threadpool Worker) 35 7 1274 02618628 1029220 Preemptive 069745A0:00000000 01a02bd8 0 MTA (Threadpool Worker) 37 8 2484 02617108 1029220 Preemptive 0EBFFB18:00000000 01a02bd8 0 MTA (Threadpool Worker) System.AccessViolationException 0ebee9dc 38 9 2234 026156a0 1029220 Preemptive 0AAED5CC:00000000 01a02bd8 0 MTA (Threadpool Worker) 39 10 3858 02617b98 1029220 Preemptive 0CB7BEE0:00000000 01a02bd8 0 MTA (Threadpool Worker) 下面的第37号线程分明的记录了异样 System.AccessViolationException，前面还跟了一个异样对象的地址 0ebee9dc ，接下来就能够用 !do 给打印进去。 ...

一：背景1. 讲故事我在年前写过一篇对于CPU爆高的剖析文章 再记一次 应用服务器 CPU 暴高事变剖析 ，过后是给同济做我的项目降级，看过那篇文章的敌人应该晓得，最初的论断是运维人员谬误的将 IIS 应用程序池设成 32bit 导致了事变的产生，这篇算是后续，拖了良久才续上哈。 犹记得那些天老板天天找咱们几个人散会，大略老板是在传导甲方给过去的压力，人晦气就是这样，你说 CPU 爆高可怕吧，我硬是给摁上来了，好了，Memory 又爆高了，尼玛我又给摁上来了，接着数据库死锁又来了，你能领会到这种压力吗？ 就像我在朋友圈发的那样，程序再不跑我就要跑了。 所以有时候敬敬风水还是很有必要的，有点扯远了哈，这篇咱们来看看程序的内存暴涨如何去排查，为了让你更有趣味，来一张运维发的内存监控图。 从图中能够看出，9点开始内存直线暴涨，相对触目惊心，要是我的小诺安这样暴涨就好了，接下来 windbg 谈话。 二： windbg 剖析1. 说一下思路内存暴涨了，最怕的就是 非托管层 出了问题，它的排查难度相比 托管层 要难10倍以上，所以遇到这类问题，先祷告一下吧，gc堆也罢，loader堆也不怕，所以先看看是否 过程内存 ≈ gc堆内存 ? 2. 排查托管还是非托管排查形式也很简略，通过 !address -summary 看看过程的已提交内存，如下输入： 0:000> !address -summary--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_FREE 261 7fb`4b151000 ( 7.982 TB) 99.77%MEM_RESERVE 278 2`6aafc000 ( 9.667 GB) 51.35% 0.12%MEM_COMMIT 2199 2`4a3a3000 ( 9.160 GB) 48.65% 0.11%能够看到已提交内存是 9.1G，接下来看下 gc 堆的大小，应用 !eeheap -gc 即可。 ...

一：背景1. 讲故事这几天看的 dump 有点多，有点伤神伤脑，早晨做梦都是dump，明天早上头晕晕的到公司就听到背地共事埋怨他负责的WPF程序挂死了，而后测试的小姑娘也跟着埋怨。。。嗨，也不晓得是哪一个迭代改进去的问题，反正客户不起义问题都不大。 不过我听到程序无响应，内心深处真的是一拘灵。。。本能反馈吧，给他发了一个 procdump 过来生成两个 dump 发过来。 话说回来，WPF这种带UI界面的挂死问题其实很好剖析的，无非就是 UI线程 失去响应了，至于为啥失去响应了，必定是做了什么见不得光的事件，比方耍小聪明用 Task.Result，还有一点要特地留神的是 UI 独有的 SynchronizationContext，如 Winform 的 ： WindowsFormsSynchronizationContext ,WPF 的 DispatcherSynchronizationContext，前面我筹备开一篇文章用 Windbg 深刻分析一下这个死锁造成的起因，好，说了这么多，dump 也到了，上 Windbg 剖析吧。 二： windbg 剖析1. 审查UI线程做法很简略，先通过 ~0s 切到0号，也就是UI线程，再通过 !dumpstack 调出UI线程的托管和非托管栈，为了爱护隐衷，我就略微精简下。 0:000> ~0seax=00000000 ebx=01855bf8 ecx=00000000 edx=00000000 esi=00000000 edi=00000000eip=776a171c esp=014fe3b8 ebp=014fe410 iopl=0 nv up ei pl nz na pe nccs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206ntdll!NtWaitForSingleObject+0xc:776a171c c20c00 ret 0Ch0:000> !dumpstackOS Thread Id: 0x4ee0 (0)Current frame: ntdll!NtWaitForSingleObject+0xcChildEBP RetAddr Caller, Callee014fe3b4 7468a9c5 mswsock!SockWaitForSingleObject+0x125, calling ntdll!NtWaitForSingleObject014fe410 7469932c mswsock!SockDoConnectReal+0x36b, calling mswsock!SockWaitForSingleObject014fe4b4 74698df7 mswsock!SockDoConnect+0x482, calling mswsock!SockDoConnectReal014fe544 74699861 mswsock!WSPConnect+0x61, calling mswsock!SockDoConnect014fe564 77316cf7 ws2_32!WSAConnect+0x77014fe5a0 6422aeea (MethodDesc 64088970 +0x5a DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr, Byte[], Int32, IntPtr, IntPtr, IntPtr, IntPtr))014fe5d4 6422aeea (MethodDesc 64088970 +0x5a DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr, Byte[], Int32, IntPtr, IntPtr, IntPtr, IntPtr))014fe5f4 641c72eb (MethodDesc 63ff4310 +0x4b System.Net.Sockets.Socket.DoConnect(System.Net.EndPoint, System.Net.SocketAddress)), calling 1d4d538c014fe628 642160c5 (MethodDesc 640847c4 +0x7d System.Net.Sockets.Socket.Connect(System.Net.EndPoint)), calling (MethodDesc 63ff4310 +0 System.Net.Sockets.Socket.DoConnect(System.Net.EndPoint, System.Net.SocketAddress))014fe644 1d4d5bd3 (MethodDesc 1c93d404 +0x33 xxx.SocketHelper.xxxSocket.Connect(System.Net.IPEndPoint)), calling (MethodDesc 640847c4 +0 System.Net.Sockets.Socket.Connect(System.Net.EndPoint))014fe660 1d4d5834 (MethodDesc 1c01df50 +0x114 xxx.MainWindow.Connect()), calling (MethodDesc 1c93d404 +0 xxx.Utilities.SocketHelper.xxxSocket.Connect(System.Net.IPEndPoint))014fe714 1d4d8d84 (MethodDesc 1c01e094 +0x9c xxx.MainWindow.<IniTimer>b__18_0(System.Object, System.EventArgs)), calling (MethodDesc 1c01df50 +0 xxx.MainWindow.Connect())从下面的调用堆栈能够看出，MainWindow 中做了一个 Socket.Connect 连贯，最初卡死在非托管的 mswsock!SockDoConnectReal办法上，应该是 Socket 连不上造成的，既然是 Socket ，把它的 ip 和 port 拿进去 telnet 一下不就好啦，对吧，能够用 !dso 把以后线程栈中所有的托管对象找进去。 ...

应用C#进行利用开发时，有时须要在程序配置文件中增加自定义的配置项，此时能够应用ConfigurationSection。 本文参考链接：ConfigurationSection、ConfigurationElement、ConfigurationElementCollection、ConfigurationProperty及James Johnson的回复。文中有误的中央欢送大家交换斧正。 ConfigurationProperty示意配置元素的一个个性或子级。能够设置其名称、类型和默认值 ，并能够指定该属性是否是必须的，是否为Key等。 ConfigurationElement示意配置文件中的配置元素，每一条配置项对应一条ConfigurationElement。ConfigurationElement是抽象类，通过继承该类能够增加自定义配置属性。 ConfigurationElementCollection示意配置文件中元素的汇合，蕴含一组配置项。ConfigurationElementCollection继承ConfigurationElement，并实现ICollection接口。 ConfigurationSection示意配置文件中的节。通过继承该类能够不便的扩大自定义的节点信息，通过ConfigurationManager.GetSection()办法能够获取到自定义的Section。 示例// config配置文件<configSections> <section name="customSection" type="ConsoleApplication1.CustomConfigurationSection,ConsoleApplication1"/></configSections><customSection> <customElementsCollection> <customElement name="name1" content="content1"/> <customElement name="name2" content="content2"/> <customElement name="name3" content="content3"/> </customElementsCollection></customSection>// ConfigurationElementpublic class CustomConfigurationElement : ConfigurationElement{ public CustomConfigurationElement(string name, string content) { this.Name = name; this.Content = content; } public CustomConfigurationElement() { } [ConfigurationProperty("name", IsRequired = true, IsKey = true)] public string Name { get { return (string)this["name"]; } set { this["name"] = value; } } [ConfigurationProperty("content", IsRequired = true)] public string Content { get { return (string)this["content"]; } set { this["content"] = value; } }}// ConfigurationElementCollectionpublic class CustomConfigurationElementCollection : ConfigurationElementCollection{ public CustomConfigurationElementCollection() { } protected override ConfigurationElement CreateNewElement() { return new CustomConfigurationElement(); } protected override object GetElementKey(ConfigurationElement element) { return ((CustomConfigurationElement)element).Name; } protected override bool IsElementName(string elementName) { bool isName = false; if(!string.IsNullOrEmpty(elementName)) isName = elementName.Equals("customElement"); return isName; } public override ConfigurationElementCollectionType CollectionType { get { return ConfigurationElementCollectionType.BasicMap; } } protected override string ElementName { get { return "customElement"; } } public CustomConfigurationElement this[object key] { get { return (CustomConfigurationElement)BaseGet(key); } } public CustomConfigurationElement this[int index] { get { return (CustomConfigurationElement)BaseGet(index); } set { if(BaseGet(index) != null) BaseRemoveAt(index); BaseAdd(index, value); } }}// ConfigurationSectionpublic class CustomConfigurationSection : ConfigurationSection{ public CustomConfigurationSection() { } [ConfigurationProperty("customElementsCollection", IsDefaultCollection = false)] public CustomConfigurationElementCollection CustomElementsCollection { get { return (CustomConfigurationElementCollection)base["customElementsCollection"]; } }}// usepublic static void ReadConfigurationSection(string sectionName){ try { Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None) as Configuration; var customSection = config.GetSection(sectionName) as CustomConfigurationSection; if(customSection == null) { Console.WriteLine($"read failed: {sectionName} is null"); return; } Console.WriteLine("custom configuration section info:"); for (int i = 0; i < customSection.CustomElementsCollection.Count; ++i) { Console.WriteLine($"\tName:{customSection.CustomElementsCollection[i].Name} Content:{customSection.CustomElementsCollection[i].Content}"); } } catch (ConfigurationErrorsException err) { Console.WriteLine($"read configuration error: {err.Message}"); }}

一：背景1. 讲故事上周四有位敌人加wx征询他的程序呈现 CPU + 线程 双高的状况，心愿我能帮忙排查下，如下图： 从截图看只是线程爆高，没看到 cpu 爆高哈，有意思的是这位敌人说他： 始终在手动回收 ，不晓得为啥看着特地想笑，但笑着笑着就哭了。 可能敌人晓得老规矩，发了两份dump过去，接下来我就能够动工了，既然说高峰期分分钟上千个线程，和我前几天分享的那篇 串口 的问题很像，必定是个别线程退不出 锁，导致 CLR 须要创立更多的线程池线程来应酬一直累积的 Work Queue，所以还是得优先看 同步块表，还是那句话，十个人用锁，八个人用 lock 。 二： windbg 剖析1. 查找 CLR 同步块表能够用 !syncblk 看看有没有 lock 的状况。 0:000> !syncblkIndex SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner 95 00000262b8a30ca8 193 1 00000262b8a36b50 116b8 53 0000025e2a8ded70 System.Object 118 00000262b8a32098 107 1 00000262bad503b0 710c 135 00000260ea8a9b00 NLog.Logger 200 00000262ba236cc8 13 1 00000262b9df1660 8858 69 0000025e2a8dcdf0 System.Object-----------------------------Total 305CCW 3RCW 6ComClassFactory 0Free 116尽管卦象上呈现了超过失常指标的持有锁值：193，107，13，但直觉更通知我，是不是死锁啦？？？ 用 sosex 扩大的 !dlk 命令能够自动检索是不是真的有？ ...

一：背景上一篇咱们聊到了如何通过 procdump 抓取 cpu爆高 和 内存暴涨 两种状况，这一篇再聊聊如何去抓程序 挂死 和 意外退出。 二：程序挂死1. 定义程序挂死 简略的说就是程序没有响应，既然没响应了，可能 死锁, 可能 负载过大线程池耗尽 等等状况，万千世界，啥状况都有。 既然是用 procdump 去抓，我得先理解下它对 挂死 (hung on) 的定义？ -h Write dump if process has a hung window (does not respond to window messages for at least 5 seconds).从下面的定义看，人家貌似是判断窗口是否在指定工夫内响应 windows音讯 来判断的，我晓得你在想什么，你寻找的web申请响应工夫过长，这种场景通过 -h 是抓不到的，我感觉它特地适宜那些带有 GUI 程序的抓取，比如说：（WPF，Winform） 。 2. 案例演示当初我筹备创立一个简略的 winform 程序，在 button 事件中成心让主线程sleep造成程序假死，参考代码如下： public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void button1_Click(object sender, EventArgs e) { Thread.Sleep(1000 * 10); MessageBox.Show("clicked me!"); } } ...

一：背景1. 讲故事上个月有个老朋友找到我，说他的站点晚顶峰 CPU 会忽然爆高，发了两份 dump 文件过去，如下图： 又是经典的 CPU 爆高问题，到目前为止，对这种我还是有一些教训可循的。 抓 2-3 个 dump第一个：有利于算两份 dump 中的线程时间差，从而推算最耗时线程。 第二个：有时候你抓的dump刚好线程都解决完了，cpu 还未实在回落，所以剖析这种dump意义不大，我是吃了不少亏。 优先揣测是否为 GC 捣鬼当初的码农都精怪精怪的，根本不会傻傻的写出个死循环，绝大部分都是遇到某种 资源密集型 或 计算密集型 场景下导致非托管的 GC 出了问题。 好了，有了这个先入为主的思路，接下来就能够用 windbg 去占卜了。 二： windbg 剖析1. GC 捣鬼剖析GC 捣鬼的实质是 GC 呈现了回收压力，尤其是对 大对象堆 的调配和开释，大家应该晓得 大对象堆 采纳的是链式管理法，不到万不得已 GC 都不敢回收它，所以在它下面的调配和开释都是一种 CPU密集型 操作，不信你能够去 StackOverflow 上搜搜 LOH 和 HighCPU 的关联关系。 2. 应用 x 命令搜寻在 windbg 中有一个快捷命令 x ，可用于在非托管堆上检索指定关键词，检索之前先看看这个 dump 是什么 Framework 版本，决定用什么关键词。 0:050> lmvstart end module name00b80000 00b88000 w3wp (pdb symbols) c:\mysymbols\w3wp.pdb\0CED8B2D5CB84AEB91307A0CE6BF528A1\w3wp.pdb Loaded symbol image file: w3wp.exe Image path: C:\Windows\SysWOW64\inetsrv\w3wp.exe Image name: w3wp.exe71510000 71cc0000 clr (pdb symbols) c:\mysymbols\clr.pdb\9B2B2A02EC2D43899F87AC20F11B82DF2\clr.pdb Loaded symbol image file: clr.dll Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll Image name: clr.dll Browse all global symbols functions data Timestamp: Thu Sep 3 03:30:58 2020 (5F4FF2F2) CheckSum: 007AC92B ImageSize: 007B0000 File version: 4.8.4261.0 Product version: 4.0.30319.0从 File version 上能够看出以后是基于 Net Framework 4.8 的，好了，用 x clr!SVR::gc_heap::trigger* 看看有没有触发 gc 的操作。 ...

一：背景1. 讲故事前天有位粉丝敌人在后盾留言让我帮忙看看他的 Winform程序 UI无响应 + 410线程 到底是啥状况，如下图： 说实话，能看到这些实在案例我是特地喜爱的 ，就像医生看病，光停留在实践和那些 demo 上，那是没有前途的，如果有敌人在这块搞不定的话，我能够收费帮你解读 dump，再附送一篇博客详述。 好了，言归正传，既然粉丝敌人曾经提到了高达 410 线程，我本能反馈就是要么高负载，要么野线程，后者大多是有数新呈现的线程卡在某个锁上。 WinForm 呈现高负载的状况，我至今还是没遇到，如果说卡在某个锁上，根本都属于这类，有了这个先入为主的思路，接下来就能够祭出 windbg 一探到底了。 二： windbg 剖析1. 查找 CLR 同步块表十个人用锁，八个人会用 lock, 所以先用 !syncblk 看看程序的锁状况。 0:000> !syncblkIndex SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner 76 070e5fa4 67 1 17367570 15e8 218 03e6dd68 System.IO.Ports.SerialStream-----------------------------Total 789CCW 39RCW 2ComClassFactory 1Free 535我去，从卦象上来看状况很不好，我来简略剖析下。 MonitorHeld = 67这个 67 示意以后有 1 个线程持有锁，有 33 个线程在期待锁，必定有敌人想问怎么算的？很简略：当一个线程持有了锁的时候 MonitorHeld+1 ，当一个线程在期待锁的时候 MonitorHeld+2 ，所以表达式就是: 67= [1 + 66=(33*2)]。 ...

一：背景置信很多人都晓得通过 工作管理器 抓取dump，尽管简略粗犷，但无奈满足程序的无数种死法，比方： 内存收缩，程序爆炸CPU爆高，程序累死利用无响应，用户气死意外退出，和人生一样既然手工太弱鸡，那有什么好的工具呢？ 除了 adplus，本文举荐一款神器 procdump, 下载地址：https://docs.microsoft.com/zh... ,还能反对 linux ，具体怎么装置就不细说了。 二：内存收缩，程序爆炸内存收缩 这种状况我置信很有敌人都遇到过，我见过最多的案例就是用了小缓存 static，而后有意无意的遗记开释，导致有限沉积终爆炸，那这种怎么用 procdump 去抓呢？ 为了不便演示，我先写一个有限分配内存的例子。 static void Main(string[] args) { List<string> list = new List<string>(); for (int i = 0; i < int.MaxValue; i++) { list.Add(string.Join(",", Enumerable.Range(0, 10000))); } Console.ReadLine(); }将程序跑起来后，设置 procdump 在内存超过 1G 的时候主动抓取全内存 dump，应用如下命令. C:\Windows\system32>procdump ConsoleApp2 -m 1024 -ma E:\net5\ConsoleApp1\ConsoleApp2\bin\DebugProcDump v10.0 - Sysinternals process dump utilityCopyright (C) 2009-2020 Mark Russinovich and Andrew RichardsSysinternals - www.sysinternals.comProcess: ConsoleApp2.exe (24112)Process image: E:\net5\ConsoleApp1\ConsoleApp2\bin\Debug\ConsoleApp2.exeCPU threshold: n/aPerformance counter: n/aCommit threshold: >= 1024 MBThreshold seconds: 10Hung window check: DisabledLog debug strings: DisabledException monitor: DisabledException filter: [Includes] * [Excludes]Terminate monitor: DisabledCloning type: DisabledConcurrent limit: n/aAvoid outage: n/aNumber of dumps: 1Dump folder: E:\net5\ConsoleApp1\ConsoleApp2\bin\Debug\Dump filename/mask: PROCESSNAME_YYMMDD_HHMMSSQueue to WER: DisabledKill after dump: DisabledPress Ctrl-C to end monitoring without terminating the process.[21:23:43] Commit: 1087Mb[21:23:43] Dump 1 initiated: E:\net5\ConsoleApp1\ConsoleApp2\bin\Debug\ConsoleApp2.exe_210323_212343.dmp[21:23:43] Dump 1 writing: Estimated dump file size is 1179 MB.[21:23:44] Dump 1 complete: 1179 MB written in 1.3 seconds[21:23:44] Dump count reached.从最初五行能够看出，当内存达到 1087M 的时候主动生成了 dump 文件，接下来用 windbg 看一看。 ...

一：背景1. 讲故事前天wx上有个敌人丢给我一个dump，让我帮忙鉴定一下某些敏感信息在内存中是否也是加密的，当初数据安全很重要，不仅数据库中的信息要加密，灌到内存后数据同样也需密文存储，随用随解密，争取平安最大化，此为背景，接下来就是我艹，这咋让我鉴定呀？ 二：如何鉴定1. 思考我艹几秒后，冷静下来想想还是有肯定解决办法的，我先把问题化简一下。 判断内存中是否有字符串为 张三 or 李四 or 王五 的明文字符。判断内存中是否存在各自明文的 md5。下面两点检索一下，根本就能确定那些敏感信息是否加密了。 像 C# 这种托管语言有一个益处，就是所有的托管对象都是寄存在 托管堆 上，话中有话就是字符串也在 托管堆 上，所以接下来的问题是如何在堆上检索 string=张三 的字符串。 问题来了，很多时候 托管堆 上的 string 是海量的，我见过最高有几千万个，string茫茫，何时能力找到我最靓的崽呀 ，实践工夫完结，接下来开始打怪。 2. 案例演示为了可能持续聊上来，我用一个简略的例子演示一下如何通过人肉搜寻 string=张三， 先看代码。 class Program { static List<string> strList = new List<string>(); static void Main(string[] args) { strList.Add("fake"); strList.Add("张三"); Console.ReadLine(); } }接下来祭出 windbg。 用 !dumpheap -type System.String -min 8 -max 15 找到所有 10-15byte 范畴的字符串。0:000> !dumpheap -type System.String -min 8 -max 15 Address MT Size026f1228 652224e4 14 026f164c 652224e4 16 026f230c 65222d74 12 ...Statistics: MT Count TotalSize Class Name65225468 1 12 System.Collections.Generic.GenericEqualityComparer`1[[System.String, mscorlib]]65222d74 10 156 System.String[]652224e4 65 1168 System.StringTotal 76 objects从输入中能够看出，以后size范畴内有 1168 个 string，还发现这个 size 不是特地准，先不论了，string 尽管有点多，但还是能够人肉的，用 !do xxx 一一查看。 ...

一：背景置信有很多敌人在遇到应用程序各种奇葩问题后，拿下来一个dump文件，辛辛苦苦剖析了大半天，终于在某一个线程的调用栈上找到了一个可疑的办法，但 windbg 经常是以 汇编 的形式显示办法代码的，惋惜的是，现如今的汇编，有多少像咱们这些速成系码农还看的懂呢？ 接下来尖利的问题就来了，如何将这些汇编代码转成 C# 源代码，如果转不成源代码转成 IL代码也好呀，起码我努致力还是能试着看的懂的。。。 本篇我就来分享下如何把 dump 中的办法源码提取进去。 二： 从 dump 文件中提取源代码1. 案例演示为了可能演示不便，我用 .netcore 3.1 写了一个简略的demo，代码如下： namespace ConsoleApp6{ class Program { static void Main(string[] args) { Run(); } static void Run() { Console.WriteLine("hello world!"); Console.ReadLine(); } }}将程序跑起来后，应用 工作管理器, adplus, procdump 轻易哪一个抓取 dump 都能够。 2. 应用 lm + savemodule 命令提取如果你的程序足够简略，能够间接用 lm 获取程序中所有的模块，而后应用 savemodule 将模块导出为 exe/dll 物理文件，如下所示： 应用 lm 提取出所有模块0:000> lmstart end module name000002c2`264b0000 000002c2`264b8000 ConsoleApp6_2c2264b0000 (deferred) 00007ff7`e4a50000 00007ff7`e4a7f000 ConsoleApp6 (deferred) 00007ffa`a4b50000 00007ffa`a546d000 System_Private_CoreLib (deferred) 00007ffa`a5470000 00007ffa`a59df000 coreclr (deferred) 00007ffa`df070000 00007ffa`df1b2000 clrjit (deferred) ...能够隐约的看到，我有一个名为 ConsoleApp6_2c2264b0000 的模块，这就是我要提取的 ConsoleApp6.exe，顺便提一下，那个很碍眼的 ConsoleApp6 (deferred) 是 PE 文件，要问我怎么晓得的？ 试一下就好啦 ...

ASP.NET OpenAPI 能够十分不便的将咱们的Web API我的项目主动文档化，除了主动文档化以外，咱们还能够利用Azure API Management将Open API主动文档化了的Web API整合到当下最火的低代码利用当中，在这篇文章中，我将向您展现如何应用Azure API Management将Azure Functions，Power Apps和Logic Apps等等Azure Service 串联在一起。Azure API Management可能利用已文档化的API定义来公开咱们的API 端点，这些端点能够轻松应用在低代码的应用程序中。来看看这有多简略：https://www.bilibili.com/vide... 将您的API导入Azure API Management随着Visual Studio 2019 16.9的公布，咱们减少了对公布到现有Azure API Management服务实例以及创立Azure API Management的新生产模式实例的反对，所以只有您是Azure的客户，您就能够在须要时应用API Management的监督，平安和集成性能。 当您公布一个曾经整合了Swashbukle.AspNetCore(在ASP.NET Core 5 Web API我的项目中为默认整合选项)的.NET Core API我的项目到Azure App Service的时候，Azure API Management 选项卡就会呈现在公布对话框中，你能够抉择一个现成的Azure API Management实例，也能够新建一个实例。 公布实现后，您将可能间接在Azure API Management门户中测试您的API。在这里，您还能够监测流量，管制拜访权限并将API导出到其余服务（本文的下一部分中将介绍如何将API导出到其余服务）。 注：Visual Studio中只能新建Azure API Management的生产模式实例。这是Azure API Management的轻量级，无服务器版本，按执行次数免费，每月提供100万次收费调用。如果有现有的Azure API Management实例，也能够将其导入其中。该性能可用于Azure API Management的任何服务级别。   如果您不相熟Azure API Management，您能够在docs.microsoft.com上理解更多无关应用Visual Studio或Visual Studio Code将API公布到Azure API Management中的信息。     Azure API Management： ...

 大家好，我是为宽广程序员兄弟操碎了心的小编，每天举荐一个小工具/源码，装满你的收藏夹，每天分享一个小技巧，让你轻松节俭开发效率，实现不加班不熬夜不掉头发，是我的指标！ 明天小编举荐一款基于.NET 5实现的通用权限治理平台（RBAC模式）,本我的项目前后端拆散架构，开箱即用，紧随前沿技术。 简介基于.NET5实现的通用权限治理平台（RBAC模式）。整合最新技术高效疾速开发，前后端拆散模式，开箱即用。后盾基于Furion框架，多租户、分库读写拆散、缓存、数据校验、鉴权、动静API、gRPC等泛滥黑科技集一身。 前端Antd-Vue-Pro + Vue2.X开发，紧跟前沿技术，前端自带字典翻译。模块化架构设计，档次清晰，业务层举荐写到独自模块，框架降级不影响业务!外围模块包含：用户、角色、职位、组织机构、菜单、字典、日志、多利用治理、文件治理、定时工作等性能。代码量少、通俗易懂、功能强大、易扩大！开源协定 应用Apache-2.0 开源许可证协定 链接地址 公众号【Github导航站】回复关键词【权限1】获取git地址 具体性能主控面板、控制台页面，可进行工作台，剖析页，统计等性能的展现。用户治理、对企业用户和系统管理员用户的保护，可绑定用户职务，机构，角色，数据权限等。利用治理、通过利用来管制不同维度的菜单展现。机构治理、公司组织架构保护，反对多层级构造的树形构造。职位治理、用户职务治理，职务可作为用户的一个标签，职务目前没有和权限等其余性能挂钩。菜单治理、菜单目录，菜单，和按钮的保护是权限管制的根本单位。角色治理、角色绑定菜单后，可限度相干角色的人员登录零碎的性能范畴。角色也能够绑定数据受权范畴。字典治理、零碎内各种枚举类型的保护。拜访日志、用户的登录和退出日志的查看和治理。操作日志、用户的操作业务的日志的查看和治理。服务监控、服务器的运行状态，CPU、内存、网络等信息数据的查看。在线用户、以后零碎在线用户的查看。【正在实现中...】布告治理、零碎的布告的治理。文件治理、文件的上传下载查看等操作，文件可应用本地存储，阿里云oss，腾讯cos接入，反对拓展。【目前只反对本地存储...】定时工作、定时工作的保护，通过cron表达式管制工作的执行频率。系统配置、零碎运行的参数的保护，参数的配置与零碎运行机制非亲非故。【欠缺中...】邮件发送、发送邮件性能。【正在实现中...】短信发送、短信发送性能，可应用阿里云sms，腾讯云sms，反对拓展。【正在实现中...】截图 结尾 本期就分享到这里，我是小编南风吹，专一分享好玩乏味、离奇、实用的开源我的项目及开发者工具、学习资源！心愿能与大家独特学习交换，欢送关注我的公众号【Github导航站】。

[FastReport .Net]是实用于Windows Forms，ASP.NET，MVC和.NET Core的全功能[报表]解决方案。它能够在Microsoft Visual Studio 2005-2019中应用。反对.Net Framework 2.0-4.x，.NET Core 3.0及以上版本。 在FastReport .NET 2021.1的新版本中，咱们实现了对.NET 5的反对。增加了新条形码-Deutsce Post Leitcode。将RTF转换为报告对象的算法已失去显着改良。并且还增加了用于转换数字的新性能。欢送下载体验。（点击下方按钮下载） 存储和加载报告 您能够用以下形式存储报告： 办法形容： 以网页模式 咱们之前看过的典型场景，应用了这个办法。报告存储在WebReport组件的ReportResourceString属性中。这个办法有以下长处和毛病。 这是一种最简略的FastReport.Net工作形式。报表模板存储在Web表单的ViewState中。它将在客户端传输。如果报表的大小很大，可能会减慢工作速度。此办法与 ""Medium Trust "模式不兼容。报表加载是主动进行的。 在.FRX文件中 此办法假如报表存储在一个非凡文件夹 "App_Data "中的文件中。要做到这一点。 运行报表设计器：创立一个报表并将其保留到.FRX文件中。在 "解决方案资源管理器 "中，抉择 "App_Data "文件夹，右键点击，抉择 "增加|现有我的项目... "项。抉择方才保留的报表文件。抉择WebReport组件，革除其ReportResourceString属性。抉择 "ReportFile "属性，调用其编辑器，从 "App_Data "文件夹中抉择报表。此办法有以下利弊： 报表不会被传送到客户端机器上。此办法与 "中等信赖 "模式不兼容。报表加载是主动进行的。 也能够通过WebReport.StartReport事件处理程序加载报表。 StartReport事件处理程序中的代码示例(sender as WebReport).Report.Load(this.Server.MapPath("~/App_Data/report.frx"))。作为一个C#/VB.NET类 在这个办法中，你把报表作为一个类来解决。要做到这一点: 设计你的报表并保留在.cs/.vb文件中。要做到这一点，在 "保留 "对话框中抉择 "文件类型"。文件类型可能是.cs或.vb--这取决于报表中的脚本语言（能够在 "Report|Options... "菜单中更改）。将该文件蕴含在你的我的项目中。最好把它保留在 "App_Code "文件夹中。革除WebReport组件的ReportResourceString和ReportFile属性。这个办法有以下长处和毛病: 你能够把报表作为一个一般的类来应用;你能够在Visual Studio中调试报表;这是在 "Medium Trust "模式下应用报表的惟一办法。你不能编辑这样的报表。要做到这一点，你须要原始的.FRX文件。要应用报表，请创立WebReport.StartReport事件处理程序。在这个处理程序中，你应该做以下事件: 创立一个报表类的实例。注册数据。将报表设置为WebReport组件的Report属性。StartReport事件处理程序的例子。 SimpleListReport report = new SimpleListReport();report.RegisterDataAsp(your_data, "your_data_name");WebReport1.Report = report; ...

.NET 6 preview曾经上线，是时候为在BUILD 2020上发表的新.NET Multi-platform App UI（MAUI）做筹备了。对于客户端应用程序开发人员来说，这一年.NET有很多令人兴奋的变动。让咱们回顾这些亮点，并看看明年可能会产生些什么。  .NET 6的布局和我的项目执行是公开进行的，咱们有一个很棒的网站，它集中展示了整个.NET的GitHub里程碑和用户故事。您能够拜访themesof.net并在Xamarin中搜寻以查看概览。   .NET 6和挪动SDK该版本的外围是将Xamarin SDK对立到.NET。Xamarin始终是.NET的一部分，但当初它已作为外围的内容公布，与其余部件（如Blazor）共享雷同的基类库，并采纳了现代化的SDK我的项目零碎格调来提供统一的工具体验。Xamarin不再是其余相似.NET或对.NET有依赖性的货色，而是.NET自身。文档和产品页面中统一的命名形式降使这一点将更加清晰。Xamarin.Android和Xamarin.iOS当初是您能够通过.NET开发波及到的额定的平台对象，因而咱们将其称为.NET for Android 以及.NET for iOS。这些SDK自身是.NET别离与Google和Apple的本地SDK的绑定，因而它们的API并没有被重新命名。 .NET Multi-platform App UI (MAUI)Xamarin.Forms是实用于Android，iOS和UWP的跨平台挪动优先框架，.NET MAUI是Xamarin.Forms的演进。咱们领有7年的为客户提供技术支持的教训，服务对象从独立开发人员到一些全球性的大公司，咱们正在改善产品的外围性能，放慢UI渲染，投资研发统一的零碎设计模式，并从挪动端扩大到桌面端。对于Xamarin.Forms的客户，您能够把MAUI当成您当初所理解的Xamarin.Forms下一个次要版本。对于刚开始应用.NET进行多平台开发的开发人员，您能够先理解一下咱们以后为您提供哪些服务。 品质自2020年年中以来，外围团队始终专一于产品中影响较大的问题，并设计了新的控制结构体系来更好地服务于将来。Xamarin.Forms 5.0是.NET MAUI之前的最初一个次要性能版本，之后的版本公布将仅蕴含bug修复。Xamarin.Forms将继续更新直到2022年11月。 此次版本公布中并不蕴含新控件。咱们把重点放在产品质量上。咱们与您一样对新性能感到兴奋，为此，咱们非常高兴看到与Xamarin.Forms 5.0一起公布的Xamarin Community Toolkit 1.0取得了如此踊跃反馈。 当您查看咱们的github库dotnet / maui时，您会发现文件组织更加精简，与Xamarin.Forms相比，该组织形式利用了多指标构造并具备更加统一的命名形式。咱们心愿这样可能更不便贡献者们找到想要扭转的对象。开发流动正在xamarin / Xamarin.Forms库的main-handler分支沉闷地进行着，这些更新会被同步到DOTNET /MAUI中去。    性能应用程序启动和UI响应工夫是应用程序性能至关重要的两个局部。为帮忙定位这里可能呈现的性能问题，咱们在AOT，启动跟踪和疾速渲染器方面有很大的改善。.NET MAUI除了能从.NET 6自身取得性能晋升外，咱们还有几个能显著进步应用程序性能的改变！ .NET MAUI中新的handler体系结构打消了视图嵌套，缩小了出现视图所需的UI控件数量。它还从根本上将平台控件与框架自身解耦。在Xamarin.Forms中，每个渲染器都有对跨平台元素的援用，并且通常依赖于INotifyPropertyChanged工作。.NET MAUI并未应用这些渲染器，而是引入了一种称为handler的新模式。 当初，框架和平台之间的关系倒置了，平台控件所须要做的就是解决框架的需要。这不仅进步了效率，而且更容易扩大或重写。须要创立自定义渲染器或成果的日子曾经一去不复返了（咱们依然会确保自定义渲染器和成果是能够应用的）。 新的构造还使平台handler更适宜被其余框架（如Fabulous）和翻新我的项目（如Comet和Blazor）重用。咱们始终着眼于将来！ 设计针对多个平台的应用程序的设计需要和多年前相比曾经产生了很大变动。在Xamarin.Forms成立之初，大多数客户都心愿他们的Android利用看起来十分像Android，而iOS利用看起来十分像iOS。咱们曾经在Xamarin.Forms中引入了越来越多的款式和控件，并让这些款式和控件在各个平台上看起来都雷同，另外在iOS咱们还增加了Visual control API以及Material Design组件，来让您能够和在Android上领有一样的用户体验。这些致力是满足客户向咱们展现其需要的形式的一部分，并且在.NET MAUI中，咱们奠定了进一步倒退的根底。 咱们将通过Fluent UI和Material Design的款式启用full-app的应用程序主题，在现有的控件上应用必要的款式API和Visual states，并尽可能减少对控件模板的反对 。 在试验方面，咱们还启动了一个新的Visual策略，该策略联合了native控件和可绘制控件。往年晚些时候，咱们将有更多信息能够分享。对于须要1：1跨平台设计并心愿取得更好的性能，但又须要native平台反对的客户,这会很敌对的。 平台.NET MAUI在.NET 6中涵括了Android，iOS，macOS和Windows。除此之外，咱们也正在和Blazor团队一起单干，.NET 6中囊括Blazor 桌面开发。 Xamarin起源于挪动开发畛域，这当然也是大多数客户应用它的中央。之后咱们退出Xamarin.Mac利用绑定到Appkit的工具来实现Apple桌面平台开发。.NET 6当初将其称为.NET for macOS，然而，咱们看到Apple在macOS桌面开发方面朝着不一样的方向倒退，咱们心愿确保为您提供最佳体验。为此，咱们正在引入对Mac Catalyst的.NET反对，这是苹果公司提供的解决方案，可将您应用UIKit构建的iOS应用程序带到桌面，并依据须要通过其余AppKit和平台API进行扩大。您能够浏览Apple的多个第一方应用程序来亲自体验。.NET MAUI将也囊括这一办法。 ...

DependencyProperty 概念依赖属性创立自定义控件的依赖属性DependencyProperty 概念依赖属性就是一种能够本人没有值，并能通过应用Binding从数据源取得值（依赖在他人身上）的属性。领有依赖属性的对象称为"依赖对象"。 继承树上能够看出，WPF的所有UI控件都是依赖对象。 WPF开发中，必须应用依赖对象作为依赖属性的宿主，使二者联合起来。依赖对象的概念被DependencyObject类所实现，依赖属性的概念则由DependencyProperty类所实现 WPF框架的编程常常和界面打交道，常常遇到的一个状况是某个属性的值的变动会影响到多个其余对象。比方当一个Button的扭转大小超过了它的容器，他的容器应该主动调整大小。于是咱们思考在每个属性的set办法中触发一些事件，但很快咱们发现现有的性能很难满足咱们的需要，至多不能简洁丑陋的满足这些需要。实际上咱们的需要更加简单，WPF中的数据绑定，XAML语法等很多中央都和属性密切相关，咱们迫切需要一种性能更加弱小的属性。 于是在WPF中，引入了一种非凡的属性，Dependency Property。这种属性和一般的属性最大不同在于,它的值的起源并不繁多。对这种属性的取值和赋值都会能与其余对象有影响，因而能失去很大的灵活性 依赖属性创立1、输出快捷键 "Propdp" 点击 TAB 按键主动生成默认 依赖属性如下为零碎默认依赖属性 public int MyProperty{ get { return (int)GetValue(MyPropertyProperty); } set { SetValue(MyPropertyProperty, value); }}// Using a DependencyProperty as the backing store for MyProperty. This enables animation, styling, binding, etc...public static readonly DependencyProperty MyPropertyProperty = DependencyProperty.Register("MyProperty", typeof(int), typeof(ownerclass), new PropertyMetadata(0));依照本人的须要批改依赖属性名称、属性名称。依赖属性实例并非应用new操作符失去而是应用DependencyProperty.Register办法生成。 DependencyProperty.Register的参数阐明 第一个参数为int类型，示意指明以哪个CLR属性作为这个依赖属性的包装器。就是代码"MyProperty"第二个参数指明此依赖属性用来存储什么样的值。第三个参数用来指明此依赖属性的宿主是什么类型，或者说DependencyProperty.Register办法要将这个依赖属性注册到哪个类型上<font color=red>留神</font> 1.依赖属性包装器是一个CLR属性，并不是依赖属性，没有包装器，依赖属性仍旧存在。2.既然没有包装器依赖属性也存在，那么包装器是干什么用的呢?包装器的作用是以"实例属性"的模式向外界裸露依赖属性，这样，一个依赖属性能力成为数据源的一个Path。3.注册依赖属性时应用的第二个参数是一个数据类型，这个数据类型也是包装器的数据类型。DependencyProperty.Register带4个参数，第四个参数的类型是PropertyMetadata类，作用是给依赖属性的DefaultMetadata属性赋值。顾名思义，DefaultMetadata的作用就是向依赖属性的调用者提供一些根本信息，这些信息包含： CoerceValueCallback：依赖属性的值被强制扭转时此委托会被调用，此委托可关联一个函数。DefaultValue：依赖属性未被显示赋值时，若读取之则取得此默认值，不设置此值会抛出异样。IsSealed：管制PropertyMetadata的属性值是否能够更改，默认值为true。PropertyChangeCallback：依赖属性的值被扭转之后此委托会被调用，此委托可关联一个函数。<font color= blue> 探索</font> 第四个参数反对 PropertyMetadate 类型，同时它派生的UIPropertyMetadata类型以及UIPropertyMetadata派生的FrameworkPropertyMetadata 在不同类型上实现的成果略有差别，此次提出一个典型 若依赖属性为ObservableCollection<T>的时候，必须要应用FrameworkPropertyMetadata作为参数，代码如下,给DefaultVaule、DefaultUpdateSourceTrigger 赋默认值。 new FrameworkPropertyMetadata { DefaultValue = new ObservableCollection<T>(), DefaultUpdateSourceTrigger = UpdateSourceTrigger.PropertyChanged });到此刻，依赖属性创立曾经实现。 ...

《进击吧！Blazor！》是自己与张善友老师单干的Blazor零根底入门教程视频，此教程能让一个从未接触过Blazor的程序员把握开发Blazor利用的能力。视频地址：https://space.bilibili.com/48...Blazor WebAssembly 是单页利用 (SPA) 框架，用于应用 .NET 生成交互式客户端 Web 利用，采纳 C# 代替 JavaScript 来编写前端代码 本系列文章因篇幅无限，省略了局部代码，残缺示例代码：https://github.com/TimChen44/...作者：陈超超Ant Design Blazor 我的项目贡献者，领有十多年从业教训，长期基于.Net 技术栈进行架构与开发产品的工作，现就职于正泰团体。邮箱：timchen@live.com欢送各位读者有任何问题分割我，咱们共同进步。我的的 ToDo 利用基本功能曾经实现，然而本人的待办当然只有本人晓得，所以咱们这次给咱们的利用减少一些平安方面的性能。 Blazor 身份验证与受权身份验证Blazor Server 利用和 Blazor WebAssembly 利用的平安计划有所不同。 Blazor WebAssemblyBlazor WebAssembly 利用在客户端上运行。 因为用户可绕过客户端查看，因为用户可批改所有客户端代码， 因而受权仅用于确定要显示的 UI 选项，所有客户端应用程序技术都是如此。 Blazor ServerBlazor Server 利用通过应用 SignalR 创立的实时连贯运行。 建设连贯后，将解决基于 SignalR 的利用的身份验证。 可基于 cookie 或一些其余持有者令牌进行身份验证。 受权AuthorizeView 组件依据用户是否取得受权来选择性地显示 UI 内容。 如果只须要为用户显示数据，而不须要在过程逻辑中应用用户的标识，那么此办法很有用。 <AuthorizeView> <Authorized> <!--验证通过显示--> </Authorized> <NotAuthorized> <!--验证不通过显示--> </NotAuthorized></AuthorizeView>Blazor 中应用 Token在 Blazor WebAssembly 模式下， 因为利用都在客户端运行，所以应用 Token 作为身份认证的形式是一个比拟好的抉择。根本的应用时序图如下 对于平安要求不高的利用采纳这个办法简略、易保护，齐全没有问题。 然而 Token 自身在安全性上存在以下两个危险： ...

微软的 Entity Framework 是一个开源的 对象-关系映射 ORM 框架，它帮忙咱们买通了 数据库的数据模型 到 代码层的畛域模型，Entity Framework 简化了应用程序对数据库的 CURD 操作，而且还向高层屏蔽了数据是如何长久化到数据库的。 说的具体一点就是 DbContext 充当了数据库到畛域模型之间的桥梁，这篇文章咱们将会探讨如何配置 DbContext 并应用 Entity Framework Core provider 对数据库进行 CURD 操作。 DbContextDbContext 是 EF 中十分重要的一个组件，它扮演着 Database 的会话连贯，应用它能够查问数据到你的 entitys 汇合中，也能够通过它将 entitys 保留到底层数据库中， EntityFramework Core 中的 DbContext 领有如下几个功能模块。 连贯治理查问数据长久化数据批改跟踪缓存事务管理要想应用 EntityFramework，须要通过 nuget 援用 Microsoft.EntityFrameworkCore 包，能够通过 Visual Studio 2019 的 NuGet package manager 可视化界面装置 或者 通过 NuGet package manager 命令行工具输出以下命令： dotnet add package Microsoft.EntityFrameworkCore接下来探讨下如何在 ASP.Net Core 中应用 DbContext 。 ...

记录日志的一个作用就是不便对应用程序进行跟踪和排错考察，在理论利用上都是引入 日志框架，但如果你的 日志文件 蕴含非结构化的数据，那么查问起来将是一个噩梦，所以须要在记录日志的时候采纳结构化形式。 将日志结构化能够更容易的查问和剖析，做法就是在写入的时候定义好数据的格局，这种格局包含：xml，json，或者你心愿转成的任何构造。 Serilog 是一个第三方，开源的结构化日志框架，它的高层封装能够让开发者更容易的将日志记录到 console，file 和你能想到的各种 存储系统，这篇文章咱们将会探讨如何在 ASP.Net Core 中应用 Serilog。 装置 Serilog应用 Visual Studio 新建 ASP.Net Core 我的项目，接下来从 NuGet 上拉几个包，具体如下： Serilog这个包提供了对根本的结构化日志的性能反对。 Serilog.AspNetCore这个包提供了 Serilog 对 AspNetCore 的反对。 Serilog.Settings.Configuration这个包买通了 Serilog 和 Configuration ，这样你就能够间接从 appsettings.json 中读取配置。 Serilog.Sinks.ConsoleConsole接收器顾名思义就是将 Serilog 的日志输入到 Console。 Serilog.Sinks.RollingFile实现了对 滚动文件 的反对。 应用 Serilog SinkSerilog 利用 sink 个性将日志送到不同的中央，比方：text文件，数据库，甚至是 ElasticSearch 中，换句话说，sink 个性能够把日志送到它该去的中央，当所有的 nuget 包都装置好了之后，上面的代码片段展现了如何将日志送到 console 中。 public HomeController(ILogger<HomeController> logger) { using (var logConfig = new LoggerConfiguration().WriteTo.Console().CreateLogger()) { logConfig.Information("This is a test data."); }; _logger = logger; } ...

web应用程序的性能置信是大家广泛关怀的一个问题，也置信大家有很多工具可用来剖析应用程序的性能并可能找到其中的瓶颈，MiniProfiler 就是这个畛域中的一款产品，它是一款简略的，功能强大的web利用剖析工具，MiniProfiler 可用来帮忙咱们找到 慢查问, 慢响应 等问题。 MiniProfiler 可用在 Asp.Net 和 ASP.Net Core 中，这篇文章将会探讨如何应用 MiniProfiler，并通过它找到应用程序的性能问题。 装置 MiniProfiler要想应用 MiniProfiler，须要通过 nuget 援用 MiniProfiler.AspNetCore.Mvc 包，能够通过 Visual Studio 2019 的 NuGet package manager 可视化界面装置 或者 通过 NuGet package manager 命令行工具输出以下命令： dotnet add package MiniProfiler.AspNetCore.Mvc装置好之后，接下来就要将 MiniProfiler 注入到 ServiceCollection 容器中，如下代码所示： // This method gets called by the runtime. Use this method to add services to the container. public void ConfigureServices(IServiceCollection services) { services.AddControllersWithViews(); services.AddMiniProfiler(options => options.RouteBasePath = "/profiler"); }注入好之后，接下来就须要应用 UseMiniProfiler 扩大办法将其注入到 Request Pipeline 管道中，如下代码所示： ...

浏览器安全策略上的平安限度能够无效的阻止 Ajax 向另外一个域server发动申请，这就是驰名的 同源策略，那如何冲破这种限度呢？能够应用 CORS （Cross-Origin Resource Sharing） 跨域资源共享来解决此类问题，它是一个 W3C 的规范，容许你跳出浏览器所采纳的同源策略的限度，即在一个域中申请另外一个域的资源。 你能够在 WebAPI 中应用 Cors包 或者 Owin中间件 来开启CORS，值得注意的是，一个残缺的 request申请 是由 scheme + host + port 三局部组成，所以依据这三个局部就能判断以后申请是否为同源申请，如不是的话，浏览器将会被动进行阻止，如下代码所示： WebAPI 中启用 CORS要想在 ASP.NET Web API 中启动 CORS，只需通过 Nuget 装置 Microsoft.AspNet.WebApi.Cors 包即可，如下代码所示： Install-Package Microsoft.AspNet.WebApi.Cors值得注意的是，CORS 能够利用到三种作用域上。 Action 级Controller 级Global 级上面就来逐个看一下。 在 Global 级应用 CORS要想作用到全局，能够调用 HttpConfiguration 实例下的 EnableCors() 办法即可，如下代码所示： public static class WebApiConfig { public static void Register(HttpConfiguration config) { // Web API configuration and services string origin = "http://localhost:50164/IDGWebClient/"; EnableCorsAttribute cors = new EnableCorsAttribute(origin, "*", "GET,POST"); config.EnableCors(cors); } }从下面的代码能够看出，origin 指定了能够被跨域的申请， * 指定了可被容许的header头信息，GET,POST 则示意能够接管的 Http Method。 ...

ASP.NET Core 是一个轻量级，模块化的框架，罕用来在 Windows，Linux 和 MacOS 上构建高性能，现代化的web框架，不像过来的 Asp.NET，在 ASP.NET Core 中并没有内置 Cache 对象，不过你能够通过 nuget 上的扩大实现如下三种 cache： in-memory cachingdistributed cachingresponse caching在本文中，咱们来看看如何将那些不易变的数据灌到内存中实现 ASP.NET Core application 的高性能，而后我会用一些例子来阐明这些概念。 如何启用 in-memory cache要想将 in-memory cache 集成到 ASP.NET Core 中，就须要将其注入到 ServiceCollection 容器，如下代码所示： public void ConfigureServices(IServiceCollection services){ services.AddMvc(); services.AddMemoryCache();}集成好之后，接下来理解一下缓存的对立接口：IMemoryCache ，代码如下： public interface IMemoryCache : IDisposable{ bool TryGetValue(object key, out object value); ICacheEntry CreateEntry(object key); void Remove(object key);}那如何在 Controller 中应用呢？ 能够应用 Controller 的构造函数实现注入，如下代码所示： public class HomeController : Controller { private readonly ILogger<HomeController> _logger; private IMemoryCache cache; public HomeController(ILogger<HomeController> logger, IMemoryCache cache) { _logger = logger; } }到当初为止，in-memory caching 的配置全副做完，当初能够思考如何实现从 Cache 读取和写入了。 ...

当初越来越多的开发人员抉择 ASP.Net Core 构建高性能，现代化web程序，并跑在 Windows，Linux 和 MacOS 上，而高性能的一大课题就是缓存，尽管 ASP.Net Core 中并没有内建缓存对象，但能够利用 Nuget 的外接扩大实现如下三种缓存形式。 In-memory cachingdistributed cachingresponse caching在后面的文章中探讨过如何在 ASP.Net Core 中实现内存缓存 和 分布式缓存，在这篇文章中，我将会解释 Response Cache 及它的益处，而后再来看一下如何在 ASP.Net Core 中集成 response cache 中间件。 Response CacheResponse Cache 原理就是在 Http Response Header 中设置一些缓存相干的参数实现对 Response 的缓存，在 Header 中能够指定是否对所有的 Request 申请或者一些 可选的 Request 申请缓存 Resposne，指的留神的是，它不是 output 缓存，也就表明 ASP.Net Core 不会将 response 缓存在 webserver 中。 Response Cache 实际上是一种更好，更不便扩大的缓存机制，它通过在 Http Header 中设置一些缓存相干的响应头来告诉浏览器缓存指定的内容，这就躲避了 client 对 webserver 大量本不须要的申请，后续的申请都是由本地的 client cache 中间接返回，没有了单方的往返工夫消耗。 ...

 大家好，我是为宽广程序员兄弟操碎了心的小编，每天举荐一个小工具/源码，装满你的收藏夹，每天分享一个小技巧，让你轻松节俭开发效率，实现不加班不熬夜不掉头发，是我的指标！ 明天小编举荐一款.NET窗体应用程序（WinForms）界面组件NanUI。NanUI是一个凋谢源代码的 .NET / .NET Core 窗体应用程序（WinForms）界面组件。她实用于心愿应用 HTML5/CSS3 等前端技术来构建 Windows 窗体应用程序用户界面的 .NET/.NET Core 开发人员。 NanUI 的渲染引擎 WinFormium 基于谷歌可嵌入的浏览器框架 Chromium Embedded Framework，因而用户能够应用各种前端技HTML5/CSS3/JavaScript 和框架 React/Vue/Angular/Blazor 设计和开发.NET 桌面应用程序的用户界面。 同时，WinFormium 特有的 JavaScript Bridge 能够不便简洁地实现浏览器端与 .NET 之间的通信和数据交换。 性能简介浏览器承载窗体:NanUI界面组件提供了零碎原生和无边框两种不同款式的窗体可供选择，用户能够灵便抉择以达到不同的设计成果。资源处理器:NanUI界面组件内置了多种资源处理器（ResourceHandler）。用户能够针对不同的场景抉择对应的资源处理器来为前端程序提供文件、数据等资源。另外，还能够依据具体的需要开发自定义资源处理器。Javascript到.NET插件反对:NanUI界面框架容许用户编写Javascript到.NET的映射对象，并通过插件管理器注入到前端页面的Javascript上下文环境中，以此达到扩大前端性能的目标。浏览器控件:用户能够像应用.NET的WebBrowser控件一样应用NanUI界面组件提供的ChromiumWebBrowser控件。从工具箱拖入窗体，搞定。自定义CEF行为处理器:NanUI凋谢了Chromium Embedded框架的各项浏览器客户端行为处理器接口。通过自定义各个接口的响应事件，将为应用程序实现各项浏览器性能性能。多过程架构:NanUI继承了Chromium多过程体系架构。这意味着每个网页都是在独自的Chromium渲染过程中渲染的。实际上，所有的性能都在独自的过程中运行。这意味着Chromium将不会应用.NET应用程序的内存。Web渲染规范:NanUI界面组件反对包含HTML5/CSS3/Javascript(ES6)在內的所有古代浏览器渲染规范。通常，NanUI反对与它版本对应的Google Chrome浏览器雷同的网页规范。Javascript执行能力:用户能够在已加载的网页上执行JavaScript代码，并将执行后果返回到.NET环境。也能够注册新的JavaScript函数或对象，并将它们与.NET办法关联。每次JavaScript调用此函数时都会利用对应的.NET办法。子过程:NanUI提供了适应不同.NET框架的浏览器子过程程序。应用子过程程序能够实现业务过程与浏览器过程的拆散。窗体类型原生款式 零碎原生窗体款式与传统的 WinForm 利用程序界面统一，领有零碎款式的标题栏、边框和系统命令区域，相似在传统的 Form 控件上拖入 WebBrowser 控件并设置 Dock 属性为 Fill 时的样子统一。 无边框窗体 为 Formium 窗体的WindowType指定属性值Borderless即可将窗体款式设置为无边框款式。无边框款式移除了原生零碎的标题栏和边框，您能够应用整个窗体区域来绘制您的利用程序界面。 Kiosk 模式 Kiosk 款式的窗体广泛用于须要全屏展现窗体内容的场景，例如：工控上位机界面、查问机界面、数据大屏幕等。 异形窗口 应用 Layered 款式容许创立异形、半透明窗体。相似各种巨匠、各种管家提供的减速球那种成果。 亚克力特效窗体 亚克力特效是 Windows 10 创意者更新版之后提供的新性能，它容许窗体的通明或半透明区域与桌面元素进行含糊混合，实现非凡的磨砂亚克力成果。与 Layered 款式雷同，依据网页中通明或者半透明区域的设置，将实现特定成果的磨砂玻璃成果。 ...

点击获取工具>> DevExpress WPF 领有120+个控件和库，将帮忙您交付满足甚至超出企业需要的高性能业务应用程序。通过DevExpress WPF能创立有着弱小互动性能的XAML根底应用程序，这些应用程序专一于当代客户的需要和构建将来新一代反对触摸的解决方案。 应用模型视图ViewModel（MVVM）架构模式设计WPF应用程序时，可能须要形容模型或ViewModel中的列。 网格能够绑定到蕴含列设置的对象汇合，该对象设置在Model或ViewModel中进行了形容，从而最大限度地缩小了“暗藏代码”的需要。 实现视图模型假如一个雇员视图模型，它包含以下类： Employee - 蕴含员工信息（例如名字和姓氏，职务等）的数据对象。ViewModel - 员工视图模型。EmployeeData - 提供要在网格控件中显示的员工信息。Column - 形容网格列，此类提供的属性对应于所有类型的网格列的通用设置。ComboBoxColumn - 对应于ComboBoxEdit in-place编辑器的网格列，此类提供Source属性，其中蕴含组合框我的项目的列表（在此示例中，这些城市）。SettingsType - 枚举用于编辑单元格值的in-place编辑器的可能类型。C# `using System;using System.Collections;using System.Collections.Generic;using System.Collections.ObjectModel; namespace Model {public class ViewModel {public List<string> Cities { get; private set; }// Returns a list of employees so that they can be bound to the grid control.public List<Employee> Source { get; private set; }// The collection of grid columns.public ObservableCollection<Column> Columns { get; private set; }public ViewModel() {Source = EmployeeData.DataSource;List<string> _cities = new List<string>();foreach (Employee employee in Source) {if (!_cities.Contains(employee.City))_cities.Add(employee.City);}Cities = _cities;Columns = new ObservableCollection<Column>() {new Column() { FieldName = "FirstName", Settings = SettingsType.Default },new Column() { FieldName = "LastName", Settings = SettingsType.Default },new Column() { FieldName = "JobTitle", Settings = SettingsType.Default },new Column() { FieldName = "BirthDate", Settings = SettingsType.Default },new ComboColumn() { FieldName = "City", Settings = SettingsType.Combo, Source = Cities }};}}// The data item.public class Employee {public string FirstName { get; set; }public string LastName { get; set; }public string JobTitle { get; set; }public string City { get; set; }public DateTime BirthDate { get; set; }}public class EmployeeData : List<Employee> {public static List<Employee> DataSource {get {List<Employee> list = new List<Employee>();list.Add(new Employee() {FirstName = "Nathan",LastName = "White",City = "NY",JobTitle = "Sales Manager",BirthDate = new DateTime(1970, 1, 10) });return list;}}}public class Column {// Specifies the name of a data source field to which the column is bound.public string FieldName { get; set; }// Specifies the type of an in-place editor used to edit column values.public SettingsType Settings { get; set; }}// Corresponds to a column with the combo box in-place editor.public class ComboColumn : Column {// The source of combo box items.public IList Source { get; set; }}public enum SettingsType { Default, Combo }}` ...

[FastReport.Mono] 是一款为Mono Framework设计的性能全面的报表生成工具。FastReport.Mono 是一个多平台的报表解决办法。它能够利用于Windows, Linux, Mac OS X，以及任何反对Xamarin Mono的操作系统。 在FastReport Mono 2021.1的新版本中，增加了新条形码-Deutsche Post Leitcode。将RTF转换为报告对象的算法已失去显着改良。并且还增加了用于转换数字的新性能。欢送下载体验。（点击下方按钮下载） [Engine] 增加了新条形码-Deutsche Post Leitcode增加了新条形码-SberBank QR增加了将数字转换为字母的性能增加了转换的性能数字到印度语言的单词印度货币减少的卢比符号波斯语言减少了将数字转换成单词的性能乌克兰语减少了将数字转换成单词的性能+增加了Report.Prepare（int pagesLimit）办法，该办法容许筹备乐队的VisibleExpression，PrintableExpression和ExportableExpression属性的无限页面*优化工作优化了乐队的VisibleExpression，PrintableExpression和ExportableExpression属性改良了将RTF转换为报表对象的算法修复了在连贯到近程JSON时应用Web响应流阅读器的谬误修复了在VisibleExpression属性中应用某些表达式编译报表时的谬误，PrintableExpression和ExportableExpression-修复了font.list文件的一个谬误，该谬误导致异样“ System.IO.FileNotFoundException”。修复了Deutsche Post Identcode条形码中校验和计算不正确的谬误修复了ReCompile（编译后增加有谬误的程序集）修复了在Linux操作系统下打印的谬误[Designer] 修复了从新加载报告后数据库名称为空的谬误修复了在报告选项卡上双击箭头按钮创立新报告页面时的谬误[Exports] 修复了在DXF导出中导出仅蕴含空格的字符串的谬误修复了PDF导出中的谬误，导致报表中有选项卡时空格隐没修复了在导出到Excel 2007中时导出页面页脚的谬误无缝表模式修复了在Excel 2007导出中导出“ ”字符的谬误[WebReport] 在ScriptSecurity模式下增加了脚本谬误的正确视图修复了在线设计器中PDF导出的谬误修复了ParagraphOffset的谬误[资源] 更新了法语资源

[FastReport .Net]是实用于Windows Forms，ASP.NET，MVC和.NET Core的全功能报表解决方案。它能够在Microsoft Visual Studio 2005-2019中应用。反对.Net Framework 2.0-4.x，.NET Core 3.0及以上版本。 在FastReport .NET 2021.1的新版本中，咱们实现了对.NET 5的反对。增加了新条形码-Deutsce Post Leitcode。将RTF转换为报告对象的算法已失去显着改良。并且还增加了用于转换数字的新性能。欢送下载体验。（点击下方按钮下载） 输入报告 筹备好的报告能够导出为反对的格局之一。此刻，能够应用以下格局。 PDF格局HTMLRTFExcel XML (Excel 2003+)Excel 2007CSVTXTOpenOffice计算图片(Bmp, Png, Jpeg, Gif, Tiff, Metafile)通过导出过滤器进行导出。要做到这一点: 应用 "筹备 "办法筹备一个报告。创立一个export filter的实例并设置其属性。调用Report对象的Export办法。上面的示例将一个筹备好的报表导出为HTML格局。 // 筹备一份报告report1.Prepare()；// 创立一个HTML导出过滤器的实例FastReport.Export.Html.HTMLExport export = new FastReport.Export.Html.HTMLExport();// 显示导出选项对话框并进行导出。if (export.ShowDialog())report1.Export(export, "result.html")； 在这个例子中，导出设置是通过对话窗口进行的。配置FastReport.Net环境 应用工具箱中的EnvironmentSettings组件，您能够管制一些FastReport.Net环境设置。要做到这一点，请将该组件放在您的窗体上，并应用属性窗口设置其属性。 EnvironmentSettings.ReportSettings属性蕴含一些与报表相干的设置。 属性形容 语言默认语言新报表的默认脚本语言。 bool ShowProgress 决定是否须要显示进度窗口。 bool ShowPerformance 决定是否在预览窗口的右下角显示报表性能信息（报表生成工夫、耗费的内存）。 EnvironmentSettings.DesignerSettings 属性蕴含一些与设计器相干的设置。 属性阐明 图标 Icon Icon 设计器窗口的图标。 默认字体 报表中应用的默认字体。 EnvironmentSettings.PreviewSettings 属性蕴含一些与预览相干的设置。 属性形容 预览按钮 Buttons在预览的工具栏中可见的按钮集。 int PagesInCache 预览时可存储在内存缓存中的筹备页数。 ...

一：背景1. 前言大略有2个月没写博客了，不是不想写哈????，关注公号的敌人应该晓得我这两个月始终都在翻译文章，前前后后大略100篇左右吧，前几天看公号的 常读用户 降了好几十，疼爱哈，还得回过神来持续写！ 2. 讲故事上周给 武汉同济 做我的项目降级，本认为一切顺利，后果捅娄子了，第二天上午高峰期运维说生产上两台 应用服务器 cpu 被打满，影响到所有客户应用，造成了大面积瘫痪，真尬尴，得先让运维抓一个 dump 下来再重启网站，还好，老板人能够，没有问责 ????。 二：CPU 爆高问题剖析1. 找思路剖析 dump，没什么比 windbg 更业余了，不过剖析 dump 我还是比拟拿手的，那怎么剖析呢？ 最简略粗犷的做法就是看每一个线程过后都在做什么，进而揣测一下就 八九不离十 了。 2. 查看所有线程栈首先用 !t 和 !tp 看一下以后程序的 线程 和 线程池 的整体详情。 0:000> !tThreadCount: 60UnstartedThread: 0BackgroundThread: 38PendingThread: 0DeadThread: 22Hosted Runtime: no Lock ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception 11 1 2c24 02487038 28220 Preemptive 00000000:00000000 010df4f8 0 Ukn 28 2 2ca0 024bad90 2b220 Preemptive 00000000:00000000 010df4f8 0 MTA (Finalizer) 30 3 2d04 024f1450 102a220 Preemptive 00000000:00000000 010df4f8 0 MTA (Threadpool Worker) 31 4 2054 024fb188 21220 Preemptive 00000000:00000000 010df4f8 0 Ukn 32 6 1128 02574400 1020220 Preemptive 00000000:00000000 010df4f8 0 Ukn (Threadpool Worker) 2 5 27ac 02520da8 20220 Preemptive 00000000:00000000 010df4f8 0 Ukn 35 17 2c44 1cc362c8 202b220 Preemptive 00000000:00000000 024fa838 1 MTA 36 20 1740 1cccc748 21220 Preemptive 00000000:00000000 010df4f8 0 Ukn 37 21 16c4 1cc08240 21220 Preemptive 00000000:00000000 010df4f8 0 Ukn 38 22 16a8 1ccd28b8 21220 Preemptive 00000000:00000000 010df4f8 0 Ukn ....0:000> !tpCPU utilization: 97%Worker Thread: Total: 21 Running: 21 Idle: 0 MaxLimit: 8191 MinLimit: 8Work Request in Queue: 23 Unknown Function: 6d92a17f Context: 0109b5f0 Unknown Function: 6d92a17f Context: 0107ed90 Unknown Function: 6d92a17f Context: 0104e750 Unknown Function: 6d92a17f Context: 010a0200 AsyncTimerCallbackCompletion TimerInfo@207f8008 AsyncTimerCallbackCompletion TimerInfo@0251b418 Unknown Function: 6d92a17f Context: 01096c78 Unknown Function: 6d92a17f Context: 01081398 AsyncTimerCallbackCompletion TimerInfo@024d0120 Unknown Function: 6d92a17f Context: 010a9a20 Unknown Function: 6d92a17f Context: 01057950 Unknown Function: 6d92a17f Context: 0104c2d0 Unknown Function: 6d92a17f Context: 010943d8 Unknown Function: 6d92a17f Context: 0107a180 Unknown Function: 6d92a17f Context: 010a7418 Unknown Function: 6d92a17f Context: 010839a0 Unknown Function: 6d92a17f Context: 010678d0 Unknown Function: 6d92a17f Context: 010a2808 Unknown Function: 6d92a17f Context: 0105c250 Unknown Function: 6d92a17f Context: 0108abb8 Unknown Function: 6d92a17f Context: 0108f7c8 Unknown Function: 6d92a17f Context: 0108d1c0 Unknown Function: 6d92a17f Context: 20896498--------------------------------------Number of Timers: 0--------------------------------------Completion Port Thread:Total: 1 Free: 1 MaxFree: 16 CurrentLimit: 1 MaxLimit: 1000 MinLimit: 8从下面的输入大略能够看到如下几点信息： ...

ASP.Net Core 提供了多种类型的缓存，除了内存缓存和响应缓存之外，还提供了对 分布式缓存 的反对。在之前的一篇文章中，我探讨了 ASP.Net Core 的内存缓存。在本文中，咱们将探讨如何在 ASP.Net Core 中应用分布式缓存，本篇就拿 Redis 和 SQL Server 作为演示。 什么是分布式缓存分布式缓存 可用于进步应用程序的性能和可伸缩性，通常 分布式缓存 被多个应用服务器共享，在分布式缓存中，缓存的数据不会落在某些个别的web服务器内存中，这些缓存数据采纳集中化存储，这样多个应用服务器都能够间接应用，这样做的益处在于，如果任何一个服务器宕机或者进行响应，其余的服务器依然可能检索缓存的数据。分布式缓存的另一个长处是，缓存的数据在服务器重启后依然存在，当你的利用集群扩大时，并不会对缓存服务器造成任何影响。 要想在 ASP.NET Core 中应用分布式缓存，须要用到 IDistributedCache 接口，在下一节中，咱们将会一起探讨 IDistributedCache 和 IMemoryCache 接口的区别。 IDistributedCache 接口在.Net Core 中用于分布式缓存的 IDistributedCache 接口要比 单机版的 IMemoryCache 接口更简单，先来看一下 IMemoryCache 接口定义。 public interface IMemoryCache : IDisposable{ bool TryGetValue(object key, out object value); ICacheEntry CreateEntry(object key); void Remove(object key);}IDistributedCache 接口是为 web farm 场景设计的, 它蕴含了一组同步和异步办法，可用于对缓存的 Add，Remove,Retrieve 操作，上面是 IDistributedCache 接口的定义。 public interface IDistributedCache{ byte[] Get(string key); Task<byte[]> GetAsync(string key); void Set(string key, byte[] value, DistributedCacheEntryOptions options); Task SetAsync(string key, byte[] value, DistributedCacheEntryOptions options); void Refresh(string key); Task RefreshAsync(string key); void Remove(string key); Task RemoveAsync(string key);}有一点值得注意，下面的 Set 办法的 value 仅反对 byte[]，有点坑哈，当然你要塞入 string 的话， 不必放心，ASP.NET Core 也提供了扩大办法对其进行反对. ...

健康检查 罕用于判断一个应用程序是否对 request 申请进行响应，ASP.Net Core 2.2 中引入了 健康检查 中间件用于报告应用程序的衰弱状态。 ASP.Net Core 中的 健康检查 落地做法是裸露一个可配置的 Http 端口，你能够应用 健康检查 去做一个最简略的活性检测，比如说：查看网络和零碎的资源可用性，数据库资源是否可用，应用程序依赖的消息中间件或者 Azure cloud service 的可用性 等等，这篇文章咱们就来探讨如何应用这个 健康检查中间件。 注册健康检查服务要注册 健康检查 服务，须要在 Startup.ConfigureServices 下调用 AddHealthChecks 办法，而后应用 UseHealthChecks 将其注入到 Request Pipeline 管道中，如下代码所示： public class Startup { // This method gets called by the runtime. Use this method to add services to the container. public void ConfigureServices(IServiceCollection services) { services.AddControllersWithViews(); services.AddHealthChecks(); } // This method gets called by the runtime. Use this method to configure the HTTP request pipeline. public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { app.UseHealthChecks("/health"); app.UseStaticFiles(); app.UseRouting(); app.UseEndpoints(endpoints => { endpoints.MapControllerRoute( name: "default", pattern: "{controller=Home}/{action=Index}/{id?}"); }); } } ...

在咱们应用程序中经常会有一些执行后台任务和任务调度的需要，那如何在 ASP.Net Core 中实现呢？ 能够利用 Azure WebJobs 或者其余一些第三方任务调度框架，如：Quartz 和 Hangfire。 在 ASP.Net Core 中，也能够将 后台任务 作为托管服务的模式，所谓的 托管服务 只须要实现框架中的 IHostedService 接口并囊括进你须要的业务逻辑作为后台任务，这篇文章将会探讨如何在 ASP.Net Core 中构建托管服务。 创立托管服务要想创立托管服务，只须要实现 IHostedService 接口即可，上面就是 IHostedService 接口的申明。 public interface IHostedService{ Task StartAsync(CancellationToken cancellationToken); Task StopAsync(CancellationToken cancellationToken);}这一节中咱们在 ASP.Net Core 中做一个极简版的 托管服务, 首先自定义一个 MyFirstHostedService 托管类，代码如下： public class MyFirstHostedService : IHostedService { protected async override Task ExecuteAsync(CancellationToken token) { throw new NotImplementedException(); } }创立 BackgroundService有一点要留神，上一节的 MyFirstHostedService 实现了 IHostedService 接口，理论开发中并不需要这样做，因为 .Net Core 中曾经提供了抽象类 BackgroundService，所以接下来重写抽象类的 ExecuteAsync 办法即可，如下代码所示： ...

ASP.Net Core 是微软开源的跨平台、可扩大、轻量级的模块化框架，可用于构建高性能的web应用程序。中间件组件能够注入到 ASP.Net Core 申请管道中实现对 Request 和 Response 的定制和批改。 ASP.Net Core 中间件能够用于查看、路由或者批改流转于Pipeline的Request和Response。本文将会探讨如何应用这些中间件来实现一些高级操作。 Use，Run，Map办法介绍Use、Map，Run办法罕用来一起构建 HTTP Pipeline 管道，上面疾速浏览一下这些办法和它们的用处。 Use该办法将会执行一个委托，而后将 交接棒 传给Pipeline的下一个中间件，因该办法短暂领有 交接棒，所以该办法可用于 短路操作。 Run该办法会执行委托并返回后果。 Map该办法将有条件地执行委托并返回后果。 注册中间件中间件是在 Startup.Configure 中进行注册，调用办法就是 Use* 系列扩大办法，上面是注册中间件的语法。 public void Configure(IApplicationBuilder app, IHostingEnvironment env){ app.UseMyCustomMiddleware<MyCustomMiddleware>();}须要留神的是，中间件的执行程序和你注册的程序是保持一致的。 Invoke 办法每个中间件都蕴含一个 Invoke() 办法, 这个办法参数是 HttpContext 的一个实例，本中间件的业务逻辑会在下一个中间件的执行前后都会被执行，如果你有点懵的话，能够理解一下什么叫：递归调用，如上面代码正文所示： public async Task Invoke(HttpContext context){ // Write code here that will be executed before the // next middleware is called await _next.Invoke(context); // call next middleware // Write code here that will be executed after the //next middleware is called }分流 Http 管道Map系扩大办法，比方：Map 和 MapWhen，它们罕用于给 pipeline 管道操作进行分流，前者是基于 Request path 进行分流，后者是基于指定的 谓语动词 进行分流。 ...

在面对 生产者-消费者 的场景下， netcore 提供了一个新的命名空间 System.Threading.Channels 来帮忙咱们更高效的解决此类问题，有了这个 Channels 存在, 生产者 和 消费者 能够各自解决本人的工作而不互相烦扰，有利于两方的并发解决，这篇文章咱们就来探讨下如何应用 System.Threading.Channels。 Dataflow vs Channel在 System.Threading.Tasks.Dataflow 命名空间下提供了一个数据流库，次要封装了 存储 和 解决 两大块,该库专一于 pipeline 解决，而 System.Threading.Tasks.Channels 次要专一于 存储 这块，从繁多职责上来说，在 生产者-消费者 场景下，Channels 比 Dataflow 性能要高得多。 为什么要应用 Channels能够利用 Channels 来实现 生产者和消费者 之间的解耦，大体上有两个益处： 生产者 和 消费者 是互相独立的，两者能够并行执行。如果生产者不给力，能够创立多个的生产者，如果消费者不给力，能够创立更多的消费者。总的来说，在 生产者-消费者 模式下能够帮忙咱们进步应用程序的吞吐率。 装置 System.Threading.Channels要想应用 Channel，须要用 nuget 援用 System.Threading.Channels 包，还能够通过 Visual Studio 2019 的 NuGet package manager 可视化界面装置 或者 通过 NuGet package manager 命令行工具输出以下命令： dotnet add package System.Threading.Channels创立 channel实质上来说，你能够创立两种类型的 channel，一种是无限容量的 bound channel，一种是有限容量的 unbound channel，接下来的问题是，如何创立呢？Channels 提供了两种 工厂办法 用于创立，如下代码所示： ...

ASP.NET Core 中内置了对依赖注入的反对，能够应用 依赖注入 的形式在运行时实现组件注入，这样能够让代码更加灵便，测试和可保护，通常有三种形式能够实现依赖注入。 构造函数注入属性注入办法注入构造函数 这种注入形式在 ASP.NET Core 中利用的是最广的，可想而知，只用这种形式也不是 放之四海而皆准 ，比如说，我不心愿每次 new class 的时候都不得不注入，换句话说，我想把依赖注入的粒度放大，我心愿只对某一个或者某几个办法独自实现注入，而不是全副，首先这能不能实现呢？实现必定是没有问题的，只需用 FromServices 个性即可，它能够实现对 Controller.Action 独自注入。 这篇文章咱们将会探讨如何在 ASP.NET Core 中应用 FromServices 个性实现依赖注入，同时我也会演示最通用的 构造函数注入 。 应用构造函数注入接下来先通过 构造函数 的形式实现依赖注入，思考上面的 ISecurityService 接口。 public interface ISecurityService { bool Validate(string userID, string password); } public class SecurityService : ISecurityService { public bool Validate(string userID, string password) { //Write code here to validate the user credentials return true; } }要想实现依赖注入，还须要将 SecurityService 注入到 ServiceCollection 容器中，如下代码所示： ...

点击获取工具>>DevExpress WinForms领有180+组件和UI库，能为Windows Forms平台创立具备影响力的业务解决方案。DevExpress WinForms能完满构建晦涩、好看且易于应用的应用程序，无论是Office格调的界面，还是剖析解决大批量的业务数据，它都能轻松胜任！DevExpress Winforms v20.2日前全新公布，此版本增强了Scheduler、Spreadsheet控件性能！ DevExpress v20.2完整版下载 SchedulerYear View WinForms Scheduler控件附带Year View显示选项，它旨在可视化逾越数天和数周的事件/约会。 Year View蕴含“ MonthCount”属性，其余与视图相干的设置与Month View设置雷同。 下拉日历和视图选择器 在日期导航栏中增加了两个新的UI元素。 Dropdown Calendar View Selector 这两个UI元素最后都是暗藏的，激活DateNavigationBar.CalendarButton和DateNavigationBar.ShowViewSelectorButton选项以使其可见。 在Timeline View中新的单元格主动高度模式 新版本将CellsAutoHeightOptions.Enabled属性重命名为AutoHeightMode，AutoHeightMode属性承受枚举值，而不是布尔值。'None'和 'Limited' 对应于'false' 和 'true'，第三个值 - “ Full”- 激活新的AutoHeight模式。 应用AutoHeight时，工夫单元将疏忽ResourcesPerPage属性值，并依据内容调整大小，这还容许用户对Timeline View进行像素滚动。 SpreadsheetExcel 2016图表（CTP） WinForms Spreadsheet控件当初反对以下Excel 2016图表类型： Box & WhiskerFunnelHistogramWaterfallPareto全面的Spreadsheet API可让您依据须要创立和编辑Excel 2016图表，WinForms Spreadsheet控件能够应用Excel 2016图表关上、打印和导出（导出为PDF）现有工作簿。 其余HTML格局 当初，您能够应用以下规范HTML标记来格式化字符串： - 在题目、工具提醒、标签等中插入超链接。www.devexpress.com要响应对链接的单击，请解决控件的HyperlinkClick事件。 - 插入换行符，您能够应用此标记在控件中显示多行文本，您也能够应用<br/>语法。大多数控件当初都反对<image>标签，要指定图像汇合，请应用控件的“ HtmlImages”属性。 叠加层 - 反对DirectX 叠加层当初反对DirectX硬件加速，当初动画在高分辨率显示器上的出现更加晦涩（并且内存应用效率更高）。 MVVM - MessageBox表单款式 咱们向MessageBoxService类增加一个新的MessageBoxFormStyle属性，此属性使您能够指定MessageBox表单的外观设置。 C# `var flyoutMsgService = MessageBoxService.CreateFlyoutMessageBoxService();flyoutMsgService.MessageBoxFormStyle = (form) => {FlyoutDialog msgFrm = form as FlyoutDialog;msgFrm.Properties.AppearanceButtons.FontStyleDelta = FontStyle.Bold;};mvvmContext1.RegisterService(flyoutMsgService);` ...

C# 8 中新增了一个十分乏味的个性，叫做 默认接口办法 (又称虚构扩大办法)，这篇文章将会探讨 C# 8 中的默认接口办法以及如何应用。 在 C# 8 之前，接口不能蕴含办法定义，只能在接口中定义方法签名，还有一个就是接口的成员默认是 public 和 abstract , 在 C# 8 之前，接口不能蕴含字段，也不能蕴含private, protected, 或者 internal 的办法成员。如果你在接口中引入了一个新成员，默认状况下你必须更新实现该接口的所有子类。 在 C# 8 中能够在接口定义办法的默认实现，而且还能够定义接口成员为 private，protect，甚至是 static，还有一点挺奇葩的，一个接口的 protect 成员是不能被实现类所拜访的，相同，它只能在子接口中被拜访，接口的 virtual 成员能够由派生接口 override，但不能被派生类 override，还有一点请留神，接口目前还不能定义 实例成员。 为什么要应用默认接口办法所谓的 默认接口办法 指的是接口中定义了一个默认实现的办法， 如果实现该接口的类没有实现默认接口办法的话，那么这个 默认接口办法 只能从接口上进行拜访，这是一个很有用的个性，因为它能够帮忙开发人员在不毁坏现有性能的状况下向接口的将来版本增加新办法。 思考上面的 ILogger 定义。 public interface ILogger { public void Log(string message); }上面的两个类扩大了ILogger接口并实现了Log()办法。 public class FileLogger : ILogger { public void Log(string message) { //Some code } } public class DbLogger : ILogger { public void Log(string message) { //Some code } }当初假如你想在ILogger接口中新增一个办法，该办法承受两个参数：一个 文本 一个 日志级别，上面的代码片段展现了日志级别的枚举类。 ...

模式匹配 是在 C# 7 中引入的一个十分????的个性，你能够在任何类型上应用 模式匹配，甚至是自定义类型，而且在 C# 8 中失去了加强，引入了大量的新模式类型，这篇文章就来探讨如何在 C# 8 中应用模式匹配。 C# 8 中的表达式模式在 C# 8 中有三种不同的形式来表白这种模式。 地位模式属性模式Tuple模式接下来看一下这些模式的相干代码及应用场景。 地位模式地位模式次要利用类中的 Deconstruct 办法将类中的属性解构到一些零散的变量中，而后实现这些零散变量的比拟，如果有点懵的话，思考上面的 Rectangle 类。 public class Rectangle { public int Length { get; set; } public int Breadth { get; set; } public Rectangle(int x, int y) => (Length, Breadth) = (x, y); public void Deconstruct(out int x, out int y) => (x, y) = (Length, Breadth); }接下来看一下如何在 Rectangle 上应用 地位模式。 ...

异步编程曾经风行很多年了，.NET 引入的 async 和 await 关键词让异步编程更具备可读性，但有一个遗憾，在 C# 8 之前都不能应用异步的形式解决数据流，直到 C# 8 引入的 IAsyncEnumerable<T> 才解决了这个问题。 说到 IAsyncEnumerable<T> ，得先说一说 IEnumerable<T> ，大家都晓得，它是用同步的形式来迭代 collection 汇合的，而这里的 IAsyncEnumerable<T> 则是用异步形式，换句话说： IAsyncEnumerable<T> 在迭代汇合的过程中不会阻塞调用线程。 IAsyncDisposable, IAsyncEnumerable<T>, IAsyncEnumerator<T>异步迭代器 容许咱们能够用异步的形式解决数据，在这之前要理解上面三个接口：IAsyncDisposable, IAsyncEnumerable<T> 和 IAsyncEnumerator<T>，他们都是在 .NET Standard 2.1 中被引入，上面的代码片段展现了这三个接口的定义。 public interface IAsyncDisposable{ ValueTask DisposeAsync();}public interface IAsyncEnumerable<out T>{ IAsyncEnumerator<T> GetAsyncEnumerator(CancellationToken token = default);}public interface IAsyncEnumerator<out T> : IAsyncDisposable{ ValueTask<bool> MoveNextAsync(); T Current { get; }}为什么要应用异步迭代器能够设想一下你有一个数据拜访层须要从数据库中一次性读取所有的数据，要想应用这个性能很简略，能够间接调用 底层提供的异步办法 XXXAsyc 实现异步调用并且一次性返回所有数据。 只有不是将所有数据都出现在页面上的话，这种解决方案问题不是太大，很多时候更多的是通过 分页读取 的模式，其实在这方面还有一个比拟好的做法就是在数据可用时立刻返回给调用者。 精确的说，这里可应用 异步迭代器 的形式来解决，如果你的办法是同步返回的话，你能够应用 return yield + 返回值 IEnumerable<T> 模式，很遗憾的是，这种形式没有扩展性，因为它是须要阻塞调用线程的。 ...

C# 8 中有几个比拟好玩的新个性，比方上面的这两个：System.Index 和 System.Range，别离对应着索引和切片操作，这篇文章将会探讨这两个类的应用。 System.Index 和 System.Range 构造体能够用它们在运行时对汇合进行 index 和 slice，上面就是 System.Index 构造体的定义。 namespace System{ public readonly struct Index { public Index(int value, bool fromEnd); }}而后就是 System.Range 构造体的定义。 namespace System{ public readonly struct Range { public Range(System.Index start, System.Index end); public static Range StartAt(System.Index start); public static Range EndAt(System.Index end); public static Range All { get; } }}应用 System.Index 从尾部向前对汇合进行索引在 C# 8.0 之前没有任何形式能够从汇合的尾部向前进行索引，当初你能够应用 ^ 操作符实现对汇合的从后往前索引，如下代码所示： System.Index operator ^(int fromEnd);接下来用一个例子来了解该操作符的应用，思考上面的string数组。 ...

在 ASP.Net Core 数据保护栈中提供了一种非常简单的办法来加密API，从而爱护数据的平安，通常落地的做法就是 数据加密 和 数据解密,这篇文章咱们就来一起看看如何应用 数据保护API。 了解加密和哈希在平安畛域，加密和hash是两个十分重要的概念，经常被开发者混用，其实这是不对的，加密是用一种加密算法将一种数据转换成另外一种数据，同时也要留神，这是一种双向操作，已加密的数据只能通过一个适合的密钥去解密，加过密的数据又称为密文，在现在的零碎间通信，数据加密还是非常简单高效的。 相比之下，hash 是一种将 text 转成 音讯摘要 的技术，要值得注意的是，hash值是惟一的，这就意味着不同的text文本不可能生成同一个 hash 值，而且还要留神的是，当 text 转成了 hash 值之后，你很难再将 hash 值再还原成 text 文本。 总的来说，加密是一种双向技术，能够应用同一个密钥对数据进行加密解密，hash是一种单向技术，它能够将 text 转成 音讯摘要，而这个摘要很难再还原成原始text。 装置 Microsoft.AspNetCore.DataProtection要想应用 数据保护API, 能够应用 Visual Studio 2019 中的 NuGet package manager 可视化界面，还能够用 NuGet package manager console 在命令行窗口中键入如下命令。 dotnet add package Microsoft.AspNetCore.DataProtection -Version 2.2.0配置数据保护API依照 ASP.NET Core 的默认常规，先将 DataProtection 注入到 ServiceCollection 中，如下代码所示。 public class Startup { // This method gets called by the runtime. Use this method to add services to the container. public void ConfigureServices(IServiceCollection services) { services.AddControllers(); services.AddDataProtection(); } }如果你想将加密和解密用到的 密钥 独自寄存到文件系统中的话，能够在注入时略微批改一下，如下代码所示： ...

ASP.Net Core MVC 实现了将 上传文件 间接映射到 model 中，只有这个 model 实现了 IFormFile 接口即可，回忆一下， model binding 的作用就是将 Request 映射到 Action 办法参数的过程，这样就简化了原来须要间接对 Request 的拜访，同时也不便后续做单元测试，本篇中的 IFormFile 接口就简化了对 Request 中的 file 拜访。 上传一个文件在这一节中咱们将会演示如何通过 IFromFile 接口来对接 client 上传一个或者多个文件，先看一下 IFromFile 接口的定义。 public interface IFormFile{ string ContentType { get; } string ContentDisposition { get; } IHeaderDictionary Headers { get; } long Length { get; } string Name { get; } string FileName { get; } Stream OpenReadStream(); void CopyTo(Stream target); Task CopyToAsync(Stream target, CancellationToken cancellationToken = null);}而后咱们创立一个 FileUploadController 类，构建一个 UploadFile 办法来接管 client 上传的文件。 ...

依赖注入技术就是将一个对象注入到一个须要它的对象中，同时它也是管制反转的一种实现，不言而喻，这样能够实现对象之间的解耦并且更不便测试和保护，依赖注入的准则早曾经指出了，应用程序的高层模块不依赖于低层模块，而应该对立依赖于形象或者接口。 在 .Net Framework 4.7.2 中引入了对依赖注入的反对，终于在 ASP.Net Web Forms 中能够应用依赖注入机制了，这篇文章将会探讨如何在 ASP.Net Web Forms 中去应用。 创立 WebForm 我的项目在 ASP.Net Web Forms 中应用依赖注入，肯定要记得将我的项目框架设为 4.7.2 以上，要么右键我的项目在属性面板上抉择 4.7.2 版本。 也能够间接在 web.config 做如下设置。 <system.web> <compilation debug="true" targetFramework="4.7.2" /> <httpRuntime targetFramework="4.7.2" />...</system.web>接下来就能够通过 Nuget 装置 AspNet.WebFormsDependencyInjection.Unity 包，能够通过 Visual Studio 2019 的 NuGet package manager 可视化界面装置 或者 通过 NuGet package manager 命令行工具输出以下命令： dotnet add package AspNet.WebFormsDependencyInjection.Unity创立实体 和 接口当初创立一个名为 Author 实体类 和 IAuthorRepository 接口。 public class Author { public int Id { get; set; } public string FirstName { get; set; } public string LastName { get; set; } } public interface IAuthorRepository { bool Create(Author author); Author Read(int id); List<Author> Read(); }而后再用 AuthorRepository 类实现一下 IAuthorRepository 接口，代码如下： ...

大家在开发完 webapi 后，常常为了不便接口单方对接，须要将 webapi 接口文档化，那有没有什么快捷可交互的文档呢？能够利用快捷工具 Swagger，它的可视化 UI 可轻松助你 API 文档化的同时还不便测试 API。 Swashbuckle 就是一个用于生成 Swagger 文档的开源工具包，这篇文章将会探讨如何利用 Swashbuckle 来为你的 Restful API 生成可交互的文档。 装置 Swagger 中间件要想利用 Swagger 文档化，须要 nuget 援用 Swashbuckle.AspNetCore 包，还能够通过 Visual Studio 2019 的 NuGet package manager 可视化界面装置 或者 通过 NuGet package manager 命令行工具输出以下命令： dotnet add package Swashbuckle.AspNetCore配置 Swagger 中间件为了配置 Swagger，在 Startup.ConfigureServices 办法中增加如下代码，留神上面的 AddSwaggerGen 办法是用于给 API 文档 增加一些元数据。 services.AddSwaggerGen(c => { c.SwaggerDoc("v1", new Info { Version = "v1", Title = "Swagger Demo", Description = "Swagger Demo for ValuesController", TermsOfService = "None", Contact = new Contact() { Name = "Joydip Kanjilal", Email = "joydipkanjilal@yahoo.com", Url = "www.google.com" } }); });接下来就要启动 Swagger了，在 Startup.Configure 办法下增加如下代码： ...