Donetframework

打算下一个项目用Blazor，学习了一个下午，这是一个很不错的全栈UI框架，基于WebAssembly技术，可以让开发人员直接用C#完成js的工作。 学习过程中，我脑子里闪现了自己经历的那个ASP.NET的WebForm时代，那时候我们用UserControl的ascx文件布局网页。查了下，果然是一脉相承。 https://docs.microsoft.com/en-us/dotnet/architecture/blazor-for-web-forms-developers/architecture-comparison 我把消息发群里，大家开始回忆曾经用过的方法，包括ViewState，GridView，IsPostBack，masterpage，repeater，这些技术确实都是一代人的回忆。 不过认真回想，微软的WwebFrom的理念是超前的， 只不过碍于当时的技术发展, 只能做成那样，后来的UI框架其实都给予它的思想。 “技术会落后，思想传承”，微软的技术从WebForm到MVC，一直到一直到Blazor，使用的WebUI的组件技术一直都没有改变，果然是汇集世界一流软件工程师的公司。

微软具有里程碑意义的Visual Studio 2022 Preview 1已经正式发布，虽然没有增加新功能，但是这个IDE重点支持64位。与此同时，微软也发布了.NET 6 Preview 5。 https://devblogs.microsoft.com/visualstudio/visual-studio-2022-preview-1-now-available/ https://devblogs.microsoft.com/dotnet/announcing-net-6-preview-5/ https://devblogs.microsoft.com/dotnet/announcing-net-maui-preview-5/ 微软在曾经在4月份在官方的博客文章种宣布了VS2022将会第一次支持64位，不再局限于4GB的内存限制，通过Windows上的64位的Visual Studio，你可以打开，编辑、运行和调试非常复杂的解决方案。 微软通过一个Gif视频展示64位的优势，最新版本的Visual Studio 2022可以轻松打开包含约1600个项目和大约300000个文件的解决方案。 微软在6月17日的文章 Visual Studio 2022 Preview 1 now available!，关键目标是测试和调整新 64 位平台的可扩展性！这是一个巨大的变化，影响到IDE的每一个部分。微软呼吁早期采用者开发者帮助开展这项工作，称"我们需要您的反馈"。VS 2019 功能不包括在预览 1： Web实时预览 仪器分析仪 Azure 云服务项目支持 T-SQL 调试器 Web负载测试和测试控制器/测试代理 Azure数据湖 Coded界面测试 DotFuscator 内置 IDE 集成 智能提示的代码查找并替换 64 位版本Visual Studio 2022 Preview 1 三个版本的早期版本（社区、专业版和企业版） ，现在已经可以下载了：https://visualstudio.microsoft.com/zh-hans/vs/preview/vs2022/

原文：bit.ly/3wFqDy9 作者：Daniel 译者：王亮 .NET 6 预览版 4 现已发布，其中包括对 ASP.NET Core 的许多新改进。 下面是此次预览版中 ASP.NET Core 的更新内容： 1 开始使用 要开始使用 .NET 6 Preview 4 中的 ASP.NET Core，请安装 .NET 6 SDK[1]。 如果你在 Windows 上使用 Visual Studio，我们建议安装 Visual Studio 2019 16.11 的最新预览版。如果你在 macOS 上，我们建议安装 Visual Studio 2019 for Mac 8.10 的最新预览版。 2 升级一个现有的项目 要将一个现有的 ASP.NET Core 应用程序从 .NET 6 Preview 3 升级到.NET 6 Preview 4。 将所有 Microsoft.AspNetCore. 引用包更新为 6.0.0-preview.4.。 更新所有 Microsoft.Extensions. 引用包更新为 6.0.0-preview.4.。 请参阅 .NET 6 中 ASP.NET Core 的完整中断变化列表[2]。 ...

时间过得真快，.NET 5我还没有来得及研究，眼看.NET 6的正式版本马上就要来了，我一直期待这个版本，因为这是LTS版本，我们团队会迁移到这个版本上来。 社区一直在不断推进.NET 6的可用性，Build 2021大会发布了Preview4，这个版本更新很大，可能与最终的版本相差不大，，正式发布RC版本是在8月份，正式发布RTM版本是在11月 ，到时后.NET正式完成.NET Framwork和.NET Core以及Mono的功能统一，还是非常值得期待的。 新产品功能： System.Text.Json support for IAsyncEnumerable System.Text.Json: Writable DOM Feature Microsoft.Extensions.Logging compile-time source generator System.Linq enhancements Significantly improved FileStream performance on Windows Enhanced Date, Time and Time Zone support CodeGen .NET Diagnostics: EventPipe for Mono and Improved EventPipe Performance IL trimming Single-file publishing CLI install of .NET 6 SDK Optional Workloads Built-in SDK version checking CLI Templates (dotnet new) 另外，还有.NET MAUI或多平台应用UI ：允许开发人员构建适用于Windows、MacOS、ios 和android的应用程序，共享单一代码库和模板。 ASP.NET Blazor混合应用程序：帮助开发人员构建基于Web的跨平台桌面体验，从而利用本机设备功能。 对ARM的加强支持：包括 Silicon 和ARM64支持。

2020年中国.NET开发 在2019年上海中国.NET开发者大会的基础上，2020年12月19日 继续以“开源、共享、创新” 为主题的第二届中国 .NET 开发者峰会（.NET Conf China 2020）在苏州人工智能智能产业创新中心拉开帷幕。微软云（Microsoft Azure）和葡萄城作为本次峰会白金赞助，明源云作为银牌赞助，朝夕教育作为铜牌赞助，泰链智能和递易智能作为星牌赞助，还有很多合作伙伴给予了峰会大力支持！本次大会以线下城市苏州为中心，覆盖北京、上海、深圳、广州、长沙、成都、徐州、山东、西安、武汉等地区，是中国 .NET 开发者的大聚会，今年由于疫情的特殊原因，组委会特意控制大会的参与人数为300人，加强线上直播方便全国的开发者参与，在CSDN和思否的战略媒体合作和线上大会直播支持下，线下参会人数突破了400人（含讲师，志愿者及合作伙伴），CSDN和思否线上直播累计触达突破40万人次。 除了大会外，我们在会前（12月18日）安排了 .NET Conf Eve（带着大家提前了解大会细节），在大会当天（12月19日）安排了采访环节同步直播，通过采访大会讲师，合作伙伴，志愿者，观众等从不同维度报道大会盛况。第二天（12月20日）特别安排了 Blazor 及 NCF 工作坊。让对Coding感兴趣的伙伴们带上电脑，沉浸式现场开发。 本次峰会完全由来自.NET技术圈开发者们的志愿者进行组织。从大家看到的精美海报，到活动现场的许多志愿者、主持人，这些都是来自对.NET 技术充满热情的优秀开发者们；尤其是那些为大家带来精彩内容的老师们，他们有时候为了PPT上的每一页内容，需要花费大量的业余时间；除了这些之外，我们还能看到许多细节，如那些设计精美的PPT、那些设计精良的文化衫、甚至还有那些小巧玲珑的贴纸图案、海报，无一不是来源于社区志愿者的精心奉献。 群英集聚，力求卓越 来自全国各地的超过400名 .NET 开发者受邀参与这次大会，超过40万人次通过直播参与大会，来自各领域的40多位资深讲师就 .NET Core ，跨平台，微服务、K8S、机器学习、大数据、IoT、混沌工程、DevOps以及自主创新等当前最为热门的科技专题做了多场精彩绝伦的演讲，与全国的 .NET 开发者一起共享技术盛宴。如此规模的中国 .NET 开发者峰会能够成功举办离不开社区伙伴、企业伙伴和志愿者的多方努力，他们共同携手，打造了中国最具影响力的 .NET 开发者峰会。 “开源、共享、创新” 这次大会的主题是“开源 共享 创新”， 这象征着中国 .NET 社区走向开放、走向世界、走向辉煌的未来趋势和历史使命。曾经， .NET 技术的发展只能依靠微软，而今，要依靠的不仅仅是微软，更是真正的社区力量。6年来，在微软 CEO 萨提亚·纳德拉的带领下，微软发生了巨大的变化，微软通过成立 .NET 基金会(dotnetfoundation.org)全面扶持开源项目。据 GitHub 最新发布的年度报告显示，按贡献者列出的增长最快的开源项目，用于跨语言和平台构建应用程序和网站的工具包和框架在今年有了显著的增长，全球.NET开发者500万，其中200万已经使用.NET Core, 在中国也有50万.NET开发者，.NET Core开发者也有20万。与此同时， .NET 社区在中国也发生了巨大变革，互联网大时代的一波波浪潮或许不会再滚滚而前，但产业互联网的大势已经拉开，而这意味着未来的时代将会成为 .NET 开发者们的主场，在 github/gitee 上活跃着很多中国的.NET 开源开发者组织，例如NCC、盛派开发者、Abp，龙芯.NET等。龙芯团队正式在大会上发布了龙芯.NET。 本次峰会持续两天，议题涵盖：云原生应用开发、 .NET 在云服务、游戏开发、区块链、大数据、机器学习、物联网的应用等。图文直播曝光量22697人次，主题演讲视频直播高峰在线观看10万人次。 大会亮点 大神云集 .NET 社区汇集全球富有实践经验的讲师、开源贡献者，来自微软、葡萄城、龙芯、明源云、蔚来汽车等超40位.NET领域权威技术专家齐聚苏州。大会开始前，来自苏州工业园区的领导** 进行了大会致辞，微软全渠道事业部CTO徐明强博士为我们带来《.NET,应您所想的应用开发平台》从.NET生态动力、.NET在全球影响力、中国.NET社区和.NET5的技术提升等多个方面微软近年来在.NET5和开源生态上做出的努力，微软大中华区Azure事业部总经理林家伟还带来了 远在美国的Julia Liuson 和 的大咖视频，龙芯.NET项目和JVM项目负责人敖琪在大会上正式发布了龙芯.NET, 来自日本东京的桂素伟线上直播分享了他基于K8S 复杂项目交付等。 ...

这两三天一直在苏州，参加2020年中国.NET开发者大会，我第一次以讲师的身份参加技术大会，以前都是作为听众，这一次也是代表公司出去做技术交流，为此做了不少准备工作。 我从大学就是用C#和.NET，一直默默关注C#开源社区，2010年玩过Mono，2013年采用Xamarin开发Android应用，从2019年起开始带来团队实践.NET Core项目，公司核心的产品已经迁移到.NET Core，今年以来带领团队完成国产化系统下的.NET Core项目改造。 我的演讲主题是国产化系统下的.NET Core实践经验和心得，这是我们过去一年多以来的实践和心得，主要包括以下几个重点： 1、国产系统现状和要求，包括CPU、操作系统和中间件的要求，如何突破目前中间件对Java的特殊保护，到底是用java重写还是迁移.NET Core，给出实用的迁移建议； 我的建议是“尽量不要重复造轮子，坚持使用DotNet”，而解决方案是如下： 2、国产化各种准备工作，重点技术预研，特别是现有系统的各个类库对.NET Core的支持情况，最终做出技术评估； 3、项目迁移工作，除了按照官方要求迁移之外，还需要考虑系统在各个平台的可移植情况，我们迁移过程中遇到的问题和解决办法； 1）、现有系统的各个类库对.NET Core的支持情况：官方API和类库基本没有问题；重点注意第三方类库，比如Lucence.NET，Zip解析等 2）、客户迁移的要求情况：如果服务器CPU架构必须是申威，要重视；如果是龙芯可以拖一拖，但是其实可以和客户提系统支持的要求。 4、项目测试，模拟各种国产CPU搭建测试环境，并对系统进行测试； 5、国产专用服务器上的系统部署实践，部署过程中的问题和解决方案。 结语：开源，自由、开放的社区是创新的力量之源，这也是互联网诞生的初心。今天主持人说到会90后超过一半，还是很希望90后、00后和未来者们都知道什么是网站URL地址，都知道怎么使用搜索引擎，不要只是被困在算法和移动应用之中。

这两个月来带领团队实践安可国产化系统下的DotNet Core，我们积累了一些经验，这里做一下记录。 1、DotNet Core可以在安可下面运行吗？ 首先，答案是肯定的。目前除了龙芯架构的服务器不支持DotNet Core（龙芯团队已经在努力，他们预计会尽快支持DotNet Core的下一个版本），其他所有平台架构的都支持，目前我们实际客户的操作系统有：ARM64(包括其扩展Aarch64)、X64，这些服务器包括飞腾、华为鲲鹏等国产服务器。 2、迁移麻烦吗？工作量有多大？ 非常靠谱。DotNet兼容性做得非常好，只要是它支持的架构的服务器，都可以很好地运行。 唯一需要考虑的是，如果项目用到的第三方库比较多，需要逐个验证迁移工作，大部分流行的第三方库都已经支持DotNet Core。 3、Java重写还是迁移？ 除非你们团队已经没有DotNet开发人员了，否则千万不要用Java重写，一方面是工作量大，另一方面是java的项目换到安可环境也是需要做很多适配工作。 而且我可以很负责任地说：DotNet Core的运行效率超级棒！几乎可以用飞快来形容。 4、迁移过程中有哪些经验？ 代码经验 我们的代码几乎无缝转移过去，唯一的地方就是全文检索lucene.net，现在这个项目已经有更新，发了十几个bata版本，我认为可以用，所以升级过来了。 另外，安可要求只能用国产达梦数据库，需要做适配，还好这些数据库基本都是开源改过来的，适配不是问题，就是一些日期等细节需要主义。 服务器经验 我们第一个项目是迁移到政务系统，要求非常严格，有专用的服务器。我们先是在通用测试服务器下（Aarch64架构CPU，中标麒麟操作系统和银河麒麟操作系统），运行起来没有任何问题。后来在专用服务器下，架构和CPU都不变，但是专用服务器涉密，所以不能随意使用命令安装库，也不能更新系统库，只需要找到合适的包用专用服务器工具安装就可以，如果是系统库文件，就让厂商安装。 5、最大的问题是什么？ 最大的问题是，安可要求服务器必须通过中间件安装系统，这些中间件其实就是web服务器，比如金蝶之类的，这里很崩溃，因为这些国产中间件只支持java,其实就是另外一个tomcat，我也认为他们基于开源改造。 后来我们的解决办法是，前后端分离，通过金蝶发布前端web站点，后端启动5000端口提供DotNet Core服务，这个并不违法安可要求。DotNet Core基于最开放的MIT开源协议，比java开放多了。

这三周来牺牲社交时间，我亲自出马、带着团队三名精干主力在“中标麒麟龙芯”下编译.Net Core 3.0、并调试程序，编译通过但Bug太多，以失败而告终，最后放弃这个平台，这不是我们的问题，这是龙芯团队的问题，他们的CPU对彻底开源的.NET支持台还很差(也许明年会好些)，不过目前我们支持“中标麒麟兆芯”，这个平台也完全符合安可要求。 从我接触到的情况来看，目前最鸡血的是那些国字号相关的企业，不过如果不涉密，但大部分也只是买来应付检查，因为国产服务器真的是几乎不能用。还有一些比较聪明的单位，直接购买云国产操作系统，但是这些国产云操作系统就是一个幌子，因为它们也是跑在“洋芯片”、寄生在“洋软件”下面而已。 Java的码农请别吐槽C#，两门语言都是“美帝”发明的开发语言哦，要说彻底支持符合国产要求，别忘了Java的SDK还有专利费，而且Java的拥有者Oracle告谷歌的侵权诉讼案还没结束呢，哈哈。 另外，很想对那些摇着民族主义旗号大喊国产的人，有本事从应用软件到开发语言彻底国产，还有哦，wifi现在澳洲公司还在收专利费、互联网也是MIT的发明、Apache基金会的总部现在还设在美国的马里兰州……这只是一场分蛋糕大盛宴，曲终人必散，苦的是那些重复造轮子的码农，还好我们已经脱离苦海。

你是否还在为微服务应该拆多小而争论不休？到底如何才能设计出收放自如的微服务？怎样才能保证业务领域模型与代码模型的一致性？或许本文能帮你找到答案。 本文是基于 DDD 的微服务设计和开发实战篇，通过借鉴领域驱动设计思想，指导微服务项目团队进行设计和开发（理论篇详见《当中台遇上 DDD，我们该如何设计微服务？》）。本文包括三部分内容：第一部分讲述领域驱动设计基本知识，包括：分层架构、服务视图、数据视图和领域事件发布和订阅等；第二部分讲述微服务设计方法、过程、模板、代码目录、设计原则等内容；最后部分以一个项目为例讲述基于 DDD 的微服务设计过程。 目标 本文采用 DDD（领域驱动设计）作为微服务设计指导思想，通过事件风暴建立领域模型，合理划分领域逻辑和物理边界，建立领域对象及服务矩阵和服务架构图，定义符合 DDD 分层架构思想的代码结构模型，保证业务模型与代码模型的一致性。通过上述设计思想、方法和过程，指导团队按照 DDD 设计思想完成微服务设计和开发。 通过领域模型和 DDD 的分层思想，屏蔽外部变化对领域逻辑的影响，确保交付的软件产品是边界清晰的微服务，而不是内部边界依然混乱的小单体。在需求和设计变化时，可以轻松的完成微服务的开发、拆分和组合，确保微服务不易受外部变化的影响，并稳定运行。 适用范围 本文适用于按照 DDD 设计方法进行微服务设计和开发的项目及相关人员。 以下情况不适用： “我们的目标是按期盖出一栋大楼来，不要跟我提什么方法，有这啰嗦的时间，还不如抓紧点时间搬砖，把楼给我快点盖好！”。 “我的工作就是让软件运行起来，能工作一切就 OK！我不需要那么多约束，什么设计方法、扩展性、业务变化、领域模型、响应能力与我无关。别耽误工期啦！先上线再说！”。 “好的软件是自己演进出来的，我们不需要设计！”。 哈哈，开个玩笑啦！其实设计不会花太多时间的！ 正文内容 不耽误大家时间了，言归正传。 DDD 分层架构视图 DDD 分层架构包括：展现层、应用层、领域层和基础层。 基于DDD的微服务设计和开发实战 DDD 分层架构各层职能如下： 展现层 展现层负责向用户显示信息和解释用户指令。 应用层 应用层是很薄的一层，主要面向用户用例操作，协调和指挥领域对象来完成业务逻辑。应用层也是与其他系统的应用层进行交互的必要渠道。应用层服务尽量简单，它不包含业务规则或知识，只为下一层的领域对象协调任务，使它们互相协作。应用层还可进行安全认证、权限校验、分布式和持久化事务控制或向外部应用发送基于事件的消息等。 领域层 领域层是软件的核心所在，它实现全部业务逻辑并且通过各种校验手段保证业务正确性。它包含业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。它负责表达业务概念、业务状态以及业务规则，具体表现形式就是领域模型。 基础层 基础层为各层提供通用的技术能力，包括：为应用层传递消息、提供 API 管理，为领域层提供数据库持久化机制等。它还能通过技术框架来支持各层之间的交互。 服务视图 微服务内的服务视图 微服务内有 Facade 接口、应用服务、领域服务和基础服务，各层服务协同配合，为外部提供服务。 基于DDD的微服务设计和开发实战 1、接口服务 接口服务位于用户接口层，用于处理用户发送的 Restful 请求和解析用户输入的配置文件等，并将信息传递给应用层。 2、应用服务 应用服务位于应用层。用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装。 应用层的服务包括应用服务和领域事件相关服务。 应用服务可对微服务内的领域服务以及微服务外的应用服务进行组合和编排，或者对基础层如文件、缓存等数据直接操作形成应用服务，对外提供粗粒度的服务。 领域事件服务包括两类：领域事件的发布和订阅。通过事件总线和消息队列实现异步数据传输，实现微服务之间的解耦。 3、领域服务 领域服务位于领域层，为完成领域中跨实体或值对象的操作转换而封装的服务，领域服务以与实体和值对象相同的方式参与实施过程。 领域服务对同一个实体的一个或多个方法进行组合和封装，或对多个不同实体的操作进行组合或编排，对外暴露成领域服务。领域服务封装了核心的业务逻辑。实体自身的行为在实体类内部实现，向上封装成领域服务暴露。 为隐藏领域层的业务逻辑实现，所有领域方法和服务等均须通过领域服务对外暴露。 为实现微服务内聚合之间的解耦，原则上禁止跨聚合的领域服务调用和跨聚合的数据相互关联。 4、基础服务 基础服务位于基础层。为各层提供资源服务（如数据库、缓存等），实现各层的解耦，降低外部资源变化对业务逻辑的影响。 基础服务主要为仓储服务，通过依赖反转的方式为各层提供基础资源服务，领域服务和应用服务调用仓储服务接口，利用仓储实现持久化数据对象或直接访问基础资源。 微服务外的服务视图 ...

今天邮箱收到github的issue更新提醒，就在昨天，龙芯(loongson)的码农们已经让.NET Core 3.1的FlightFinder例子在MIPS64跑起来了，但是更复杂的程序还得继续改，预计在今年年底加入.NET 5.x（谨慎乐观）。 .NET 本身是完全开源，比Java还要开放（想想现在Google和Oracle关于Java的专利案还没结束呢），但是MS官方已经明确.NET Core和未来的版本不会支持MIPS的CPU指令集架构（龙芯就是用这个架构级），因为太小众了，要实现就得社区自己去写。 龙芯的团队从去年11月份跑Hello World到现在做了不少工作，看社区里的几位工程师也很努力，最终应该会支持（大概率版本会落后），这个值得肯定。但是，对于龙芯来说，社区和生态太难了，要不是去年“安可”要求，估计也不会刺激他们去支持.NET Core。好的结局是“安可”推广成功，gov和army里无关紧要的系统都用（核心系统因为复杂度，怕是很难用上）。 最最要命的是：技术发展太快了，龙芯所支持的服务器市场现在已经完全靠云计算了，这些云计算不可能采用龙芯等国产芯片，这也是为什么阿里要造出概念化的飞天国产云系统的原因——为了政策需要啊！ 对于科学技术，我坚信市场化和资本化是最有效的驱动力，最近的SpaceX是又一个有力佐证。努力的人很多，最后大都做了前浪。