DotNET框架

用Windbg来分析.Net程序的dump 1. 什么是Windbg WinDbg是微软发布的一款相当优秀的源码级(source-level)调试工具，可以用于Kernel模式调试和用户模式调试，还可以调试Dump文件。 WinDbg是微软很重要的诊断调试工具: 可以查看源代码、设置断点、查看变量, 查看调用堆栈及内存情况。 Dump文件是进程的内存镜像, 可以把程序的执行状态通过调试器保存到dump文件中 2. Windbg可以解决以下问题 ◆ 内存高 ◆ CPU高 ◆ 程序异常 ◆ 程序Hang死 3. 使用windbg进行调试分析的两种方式 使用windbg调试器attach到需要调试的进程。(会暂停进程的运行) 抓取进程的dump文件，使用windbg分析dump 下载地址:https://technet.microsoft.com/en-us/sysinternals/dd996900 下载之后为压缩包，将文件解压。通过dos命令来生成dump文件。下面为一条语句为示例 procdump -ma -c 0 -s 3 -n 2 sqlservr.exe -o E:\dumps\ 这条语句的意思为：当sqkservr.exe这个进程运行时间cpu的占用超过0%，时间超过3秒，则在E:\dumps下生成一个dump文件。一直到生成2个为止。下面为命令介绍 -ma 生成full dump, 即包括进程的所有内存. 默认的dump格式包括线程和句柄信息. -c 在CPU使用率到达这个阀值的时候, 生成dump文件. -s CPU阀值必须持续多少秒才抓取dump文件. -n 在该工具退出之前要抓取多少个dump文件. -o dump文件保存目录. Sqlservr.exe可替换为进程的ID

这个项目的框架是微软顶级工程师的杰作，太牛了，终于理解为什么各类开发IDE都是海外工程师写出来了，框架设计优美、代码精炼、扩展性超强、考虑全面。ps：国内IT软件方面至少落后欧美10年(那些把开源改改就说国产世界第一就别拿来丢脸了)，得益于开源和github，我们才有机会保持这个差距。 国内对C#和.NET总是有一些误解。比如.NET Core，海外已经用得如火如荼了，社区非常活跃，并且各种新的开发理念和工具极大提高效率。我在BAT写过代码，说实话他们的软件架构理念都是实用为主，并没有从工程学角度去发展，所以只适合特点场景，但是他们垄断中国码农的话语权，导致后来者c#大都被误解。这无形中导致国内软件开发起码落后海外10年。举一个最简单例子，现在大公司也有devops，但是放到中小型公司，他们很难运用bat的这套东西，而阿里云对devops支持太差了，反观aws和azure几乎是完美支持，这里面有国情原因，也有c#被误解的原因。 我可以毫无客气地说：国内对.net的误解，其实就是落后又自大的一个缩影。看看现在华为、国产软件时不时世界第一的“亩产万金”的论断。

历史版本 C#作为微软2000年以后.NET平台开发的当家语言，发展至今具有17年的历史，语言本身具有丰富的特性，微软对其更新支持也十分支持。微软将C#提交给标准组织ECMA，C# 5.0目前是ECMA发布的最新规范，C# 6.0还是草案阶段，C# 7.1是微软当前提供的最新规范。 这里仅仅列个提纲，由于C# 5.0是具有ECMA标准规范的版本，所以选择C# 5.0作为主要版本学习，并专题学习C# 6.0,7.0版本新特性。 C#语言规范GitHub库参见：https://github.com/dotnet/csharplang C#语言路线图及开发中的特性参见： https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md 语言版本 发布时间 .NET Framework要求 Visual Studio版本 C# 1.0 2002.1 .NET Framework 1.0 Visual Studio .NET 2002 C# 1.1\1.2 2003.4 .NET Framework 1.1 Visual Studio .NET 2003 C# 2.0 2005.11 .NET Framework 2.0 Visual Studio 2005 C# 3.0 2007.11 .NET Framework 2.0\3.0\3.5 Visual Studio 2008 C# 4.0 2010.4 .NET Framework 4.0 Visual Studio 2010 C# 5.0 2012.8 .NET Framework 4.5 Visual Studio 2012\2013 C# 6.0 2015.7 .NET Framework 4.6 Visual Studio 2015 C# 7.0 2017.3 .NET Framework 4.6.2 Visual Studio 2017 C# 7.1 2017.6 .NET Framework Visual Studio 2017 v15.3预览版 C# 8.0 待发布 .NET Framework 4.7.1 Visual Studio 2017 v15.7 C# 1.0 特性 第1个版本，编程语言最基础的特性。 ...

这几天把.NETCONF所有的视频都看了一遍，感叹微软的开放力度和对C#及.NET的推进力度。我写过Delphi、VB、C、C++、C#、Object-C、PHP、JAVA、Python，这一路过来总觉得太分散了，很难真正投入到推动一门语言的地步，现在看来，C#是初恋也是最爱，真不能在乱“移情别恋”了。未来最多使用Python进行一些ML（机器学习）涉及的方面的数据工作。 针对C#和.NET我一定持续关注，而且专注于她，这是工作需要，也是自己的发展需要。 1、全面梳理C#这门语言，虽然我已经写了12年C#了。 实际行动：把微软的文档看一遍，把那几本经典的书读完。（2019到2020） 2、应用.NET Core 3.0及未来版本。 实际行动：把公司的一个项目做成兼容linux平台。（2019） 3、研究Orchard Core项目。 实际行动：把自己的blog都迁移过来。（2019到2020） 4、研究ABP项目，顺便研究微服务架构和DDD结构。 实际行动：在公司的一个项目中完成。（2019到2020） 5、机器学习ML.NET研究和Python 实际行动：自己建模完成一些数据分析和预测。（2019起步，长期工作） 6、学习Azure、AWS技术和DevOps 实际行动：考下AWS证书，并在公司一个项目中完成Azure的DevOps。（2020到2021） 另外，学习nopCommerce和CSLA .NET两个开源项目的特点，吸收特长；学习Angular和Vue前端框架。

根据微软博客的介绍，开发者可以面向 Windows、MacOS 以及 Linux 等系统平台下载 .NET Core 3.0 ： .NET Core 3.0 SDK 与运行时 Snap 安装程序 Docker 镜像 此外， ASP .NET Core 3.0 与 EF Core 3.0 也已经一同发布。 Visual Studio 2019 16.3 与 Visual Studio for Mac 8.3 亦同时发布，且需要更新才能确保 .NET Core 3.0 与 Visual Studio 的协同使用。.NET Core 3.0 为 Visual Studio 2019 16.3 中的组成部分，开发者可以选择直接升级至 Visual Studio 2019 16.3，从而立刻获取 .NET Core。 感谢所有为 .NET Core 3.0 做出贡献的朋友们！此次最新版本的发布源自数百位团队成员的努力，也包括技术社区的重大贡献。 发行说明： .NET Core 3.0 发行说明 .NET Core 2.2 -> 3.0 API 的区别 .NET Core 3.0 贡献者名单 GitHub 发行版 关于 .NET Core 3.0 的 GitHub 问题解答 3.0 版本，开发者需要了解什么？ 在深入探究 .NET Core 3.0 中的全部新功能之前，我们首先需要强调几项关键性的改进与指导内容。以下是整理出的要点清单： ...

几个月前，SignalR Core 团队发布了一个非官方版本的 ASP.NET Core SignalR。为此，开发人员有机会了解其工作原理以及 ASP.NET SignalR 与 Signal Core 新架构之间的区别。 SignalR Core 中移除了哪些特性 通过对比两个版本的 SignalR 可以发现，新版本不再支持一些重要的特性。首先是移除了对 jQuery 和其他第三方类库的依赖，因为新版本的 JavaScript 客户端是使用 TypeScript 开发的。其次是自动连接后的消息重放功能，移除该功能主要是出于性能方面的考虑。服务器需要为每一个连接维护一个缓冲区，用于保存消息，以便后续重新发送。当客户端断开连接，可以尝试重新恢复连接，然后将未发送的消息发送给客户端。可以想象，如果有很多客户端断开连接，而且每个客户端都发送大量的消息，对于服务器来说是个很大的负担。另一个被 SignalR 团队移除特性是多 Hub 端点，所以，在新版本里，每个连接只有一个 Hub。 新版本的 SignalR Core 不再支持横向扩展（Scale Out）模型，原因是 MessageBus 被当成了横向扩展的“万灵丹”，但它实际上只支持Azure Service Bus、Redis 和 SQL Server。在实际的协作场景当中（客户端到客户端），随着客户端和消息数量的增长，通过以上三种方式进行横向扩展会有瓶颈问题。 最后一个被移除的功能是多服务器间的双向复制（backplane），因为这个功能会在服务器场生成太多的流量。ASP.NET SignalR 通过 MessageBus 在服务器间复制每一个消息，因为客户端无法直接连接到服务器场，而现在，SignalR 使用粘性会话来避免在所有服务器间复制消息。这样一来，SignalR Core 就可以知道哪个客户端连接到了哪台服务器上。 SignalR Core 中增加了哪些新特性 现在让我们来看一下 SignalR Core 带来了哪些新的特性。首先是使用了二进制协议来发送和接收消息。在 ASP.NET SignalR 中只能使用 JSON 格式的文本来发送和接收消息，而现在则可以使用二进制协议，该二进制协议基于MessagePack序列化格式，比 JSON 更快、体积更小。 主机无关性是另一个非常重要的特性，有了这个特性，就可以移除对 HTTP 的依赖。现在，我们可以在 HTTP 或 TCP 之上使用 SignalR。端点 API 也是非常重要的一个特性，它是基础的构建块，用于支持主机无关性。因为新版本是基于 Microsoft.AspNetCore.Sockets 这一底层的网络抽象层，所以可以直接使用 Socket。这么说来，SignalR Hub 其实也就是一个端点。 ...

这几天终于抽出空啦看微软的Build 2019，看到.NET Core 3.0及相关技术的详细介绍，并且了解.NET的未来规划，感叹微软的伟大。 上图是.NET Core的web开发部分。 上图是.NET 平台大统一设计。 上图是.NET未来的Roadmap。 这就叫做技术领域的一统江湖。二十年前很多人嘲笑Windows的垄断和Microsoft的不开源（现在依然有老古董如此认为），如今，Sun寄人篱下并且靠着Java专利法残喘苟活。我一直觉得微软汇聚的是软件世界最优秀的工程师，这些人要是投身开源代码，那是很恐怖的，短短不到5年时间，微软现在成为开源代码贡献最大的公司。 如今.NET Core 在海外若日中天，当国内经济持续下滑，人力成本持续提高，你们就会想到用.NET Core了，一个公司只需要三名码农就可以搞定后端、前端、移动开发。不过很可惜，公司的人力部门都听CTO的，而这群Java养出来的没落贵族是不会自己变革的。 ​​​​

本文要点 WebAssembly 是一种新的客户端技术，可以在所有现代浏览器（包括移动浏览器）中实现近乎原生的性能，而且不需要插件。 许多语言，包括 C、C#、Go 和 Rust，都可以编译成面向基于栈的 WebAssembly 虚拟机的代码。 .NET 代码可以在任何地方运行，包括浏览器内部。 Blazor 是一个客户端库，它在 WebAssembly 上使用.NET 来支持借助 Razor 模板使用 C# 编写的单页应用程序。 Blazor 支持代码重用和将遗留代码移植到现代 Web 应用程序的能力。 在 2019 年 4 月中旬，微软悄悄地推出了一个年轻的框架，从“一切皆有可能”的实验阶段过渡到“我们致力于实现这一目标”的预览版。这个框架名为Blazor，因为它在浏览器中运行，并利用了一个名为 Razor 的模板系统或“视图引擎”，促成了这个.NET 开发人员几乎放弃了的场景。它不仅允许开发人员使用 C# 构建客户端代码（不需要 JavaScript），还允许开发人员在没有插件的情况下在浏览器中运行现有的.NET 标准 DLL。 Blazor 有两种托管模式。本文主要关注客户端版本。你可以阅读“Blazor 服务器端托管模型”了解更多关于服务器端版本的信息。 Silverlight 的希望 在任何地方运行.NET 的梦想始于 2006 年，当时有一个名为“Windows Presentation Foundation/Everywhere（WPF/E）”的应用程序框架以 Silverlight 的形式向公众发布。第一个版本支持通过 WPF 引入的声明性用户界面，即可扩展应用程序标记语言（Extensible Application Markup Language，简称 XAML）。该平台提供了对 UI 元素的细粒度控制，并提供了自己的文档对象模型（DOM），可以通过 JavaScript 访问。 当 Silverlight 2 在 2008 年发布时，它通过一个作为浏览器插件运行的公共语言运行时（CLR）实现.NET 的完全支持，从而加快了采用速度。开发人员可以使用任何.NET 语言来构建 Web 应用程序，利用成熟的数据绑定模式，如 Model-View-ViewMode（MVVM），并使用 REST 或 Windows Communication Foundation（WCF）客户端与 Web API 通信。看起来，.NET 开发人员可以摆脱 JavaScript 的束缚，不用再担心跨浏览器测试，而是专注于一个具有公共代码库的平台来交付他们的应用程序。 ...

今天我们非常高兴发布 .NET Core 3.0 Preview 5，它包含了新的Json serializer，支持发布单执行文件，并且更新到新的runtime roll-forward，BCL也做了一些改动。 目前可以下载.NET Core 3.0 Preview 5安装到Windows, macOS and Linux.另外，ASP.NET Core和EF Core也发布了。 具体英文地址：https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0-preview-5/

2004年，Eric Evans出版《领域驱动设计——软件核心复杂性应对之道》（简称《领域驱动设计》），10年之后，我们有了《实现领域驱动设计》。DDD将一个软件系统的核心业务功能集中在一个核心域里面，其中包含了实体、值对象、领域服务、资源库和聚合等概念。在此基础上，DDD提出了一套完整的支撑这样的核心领域的基础设施。此时，DDD已经不再是“面向对象进阶”那么简单了，而是演变成了一个系统工程。 领域，即是一个组织的业务开展方式，业务价值便体现在其中。长久以来，我们程序员都是很好的技术型思考者，我们总是擅长从技术的角度来解决项目问题。但是，一个软件系统是否真正可用是通过它所提供的业务价值体现出来的。因此，与其每天钻在那些永远也学不完的技术中，何不将我们的关注点向软件系统所提供的业务价值方向思考思考，这也正是DDD所试图解决的问题。在DDD中，代码就是设计本身，你不再需要那些繁文缛节的并且永远也无法得到实时更新的设计文档。编码者与领域专家再也不需要翻译才能理解对方所表达的意思。DDD有战略设计和战术设计之分。战略设计主要从高层“俯视”我们的软件系统，帮助我们精准地划分领域以及处理各个领域之间的关系；而战术设计则从技术实现的层面教会我们如何具体地实施DDD。 DDD之战略设计 DDD的战略设计主要包括领域/子域、通用语言、限界上下文和架构风格等概念。 1、领域和子域（Domain/Subdomain） 领域驱动设计关注点应该放在如何设计领域模型上，以及对领域模型的划分。 领域的概念：一个电商网站的领域包含了产品名录、订单、发票、库存和物流的概念。领域的划分是将一个大的领域划分成若干个子域。通常会将一个大型的软件系统拆分成若干个子系统。这种划分有可能是基于架构方面的考虑，也有可能是基于基础设施的。DDD对系统的划分是基于领域的，即基于业务。第一个问题，哪些概念应该建模在哪些子系统里面？第二个问题是，各个子系统之间的应该如何集成？如何解决？答案是：限界上下文和上下文映射图。 2、限界上下文（Bounded Context） 在一个领域/子域中，我们会创建一个概念上的领域边界，在这个边界中，任何领域对象都只表示特定于该边界内部的确切含义。这样边界便称为限界上下文。限界上下文和领域具有一对一的关系。将一个限界上下文中的所有概念，包括名词、动词和形容词全部集中在一起，我们便为该限界上下文创建了一套通用语言。通用语言是一个团队所有成员交流时所使用的语言，业务分析人员、编码人员和测试人员都应该直接通过通用语言进行交流。 上文中的各个子域之间的集成问题，是限界上下文之间的集成问题。防腐层负责与外部服务提供方打交道，还负责将外部概念翻译成自己的核心领域能够理解的概念。当然，防腐层只是限界上下文之间众多集成方式的一种，另外还有共享内核、开放主机服务等，具体细节请参考 《实现领域驱动设计》原书。限界上下文之间的集成关系也可以理解为是领域概念在不同上下文之间的映射关系，因此，限界上下文之间的集成也称为上下文映射图。 3、架构风格（Architecture） DDD并不要求采用特定的架构风格，因为它是对架构中立的。可以采用传统的三层式架构，也可以采用REST架构和事件驱动架构等。但是在《实现领域驱动设计》中，作者比较推崇事件驱动架构和六边形（Hexagonal）架构。在六边形架构中，已经不存在分层的概念，所有组件都是平等的。这主要得益于软件抽象的好处，即各个组件的之间的交互完全通过接口完成，而不是具体的实现细节。Robert C. Martin：抽象不应该依赖于细节，细节应该依赖于抽象。 采用六边形架构的系统中存在着很多端口和适配器的组合。端口表示的是一个软件系统的输入和输出，而适配器则是对每一个端口的访问方式。 DDD之战术设计 战略设计为我们提供一种高层视野来审视我们的软件系统，而战术设计则将战略设计进行具体化和细节化，它主要关注的是技术层面的实施，也是对我们程序员来得最实在的地方。 1、领域对象 领域对象能够准确地表达出业务意图，但多数时候却是充满getter和setter的领域对象，此时的领域对象已经不是领域对象了，而是Martin Fowler所称之为的贫血对象。.NET里面很好地支持非贫血对象。 2、实体vs值对象（Entity vs Value Object） 软件系统中实体表示那些具有生命周期并且会在其生命周期中发生改变的东西；而值对象则表示起描述性作用的并且可以相互替换的概念。同一个概念，在一个软件系统中被建模成了实体，但是在另一个系统中则有可能是值对象。 3、聚合（Aggregate） 聚合是DDD中最难理解的概念 ，聚合中所包含的对象之间具有密不可分的联系，他们是内聚在一起的。比如一辆汽车（Car）包含了引擎（Engine）、车轮 （Wheel）和油箱（Tank）等组件，缺一不可。一个聚合中可以包含多个实体和值对象，因此聚合也被称为根实体。聚合是持久化的基本单位，它和资源库具有一一对应的关系。 4、领域服务（Domain Service） 领域概念放在实体上不合适，放在值对象上也不合适，领域服务本来就是来处理这种场景的。比如对密码进行加密，可以创建一个 PasswordEncryptService来专门负责此事。 5、资源库（Repository） 资源库用于保存和获取聚合对象，资源库与DAO相似。但资源库和DAO存在显著区别。DAO只是对数据库的一层很薄的封装，而资源库则更加具有领域特征。另外，所有的实体都可以有相应的DAO，但并不是所有的实体都有资源库，只有聚合才有相应的资源库。资源库分为两种，一种是基于集合的，一种是基于持久化的。顾名思义，基于集合的资源库具有编程语言中集合的特征。 6、领域事件（Domain Event） 《领域驱动设计》中并没有提到领域事件，领域事件是最近几年才加入DDD生态系统的。微服务（Micro Service）的架构中，整个系统被分成了很多个轻量的程序模块，他们之间的数据一致性并不容易通过事务一致性完成，领域事件便可以用于处理上述问题，此时最终一致性取代了事务一致性，通过领域事件的方式达到各个组件之间的数据一致性。