盘点5个基于SkiaSharp开发的.Net开源形项目

       基于SkiaSharp开发的.Net开源图形项目为开发者提供了强大的跨平台图形处理能力。这些项目涵盖了从富文本编辑、码网图像绘制到二维码生成、码网报表开发和处理等多个领域，码网天使插件源码txt展现了SkiaSharp在图形处理领域的码网广泛适用性与灵活性。

       1. **富文本编辑工具**：此工具作为开源的码网富文本编辑器，支持.Net、码网.NetCoreapp2.1、码网.Net 5，码网提供丰富的码网字体样式，包括粗体、码网斜体、码网下划线等，码网同时支持Emoji和其他国际字符集的字体回退。此工具的代码地址位于github.com/toptensoftwa...。

       2. **图像绘制工具**：此基于Avalonia开发的项目可在macOS、Linux、Windows上运行，允许开发者编写.Net应用程序进行图形绘制和渲染。通过编辑C#代码，开发者可以在右侧实时查看绘制效果。项目源代码位于github.com/mattleibow/S...。

       3. **二维码开发库**：这是一个用于生成QR码的.NET库，支持生成文本、URL、二进制数据等多种类型的二维码，并能导出为PNG、大波浪指标源码JPG格式。同时，此库支持指定二维码的颜色、大小、背景等属性，并且具备跨平台能力。项目地址为github.com/guitarrapc/S...。

       4. **报表开发库**：此简单的Xamarin.Forms图表库适用于报表或移动项目开发，提供丰富的示例作为学习资源。项目地址为github.com/NdubuisiJr/s...。

       5. **处理开发库**：基于ASP.NET Core的图像处理工具，支持加载各种数据源的，包括HTTP、本地等，提供调整大小、裁剪、旋转等基本图像处理操作，并具备PDF转的功能。此库的代码地址位于github.com/usercode/Ima...。

       这些项目展示了SkiaSharp在.Net生态系统中的强大应用潜力，适合不同场景的图形处理需求。开发者可以根据项目需求选择合适的开源库进行开发。

🔥🔥基于Net6+Vue2/Vue3+Element-ui开发的RBAC通用权限管理系统

       项目源码位于：不做码农/ZrAdminNetCore

       项目起源于对现有技术栈的探索与满足。在GitHub和Gitee上，我找到了大量基于Java后端的项目，这些项目在后端依赖管理和配置上存在复杂性，同时，前端业务封装过于繁杂，三柱香指标源码导致代码难以理解。借鉴了Java Ruoyi项目的代码风格，我决定构建一个前后端分离的.NET项目，旨在提供一个更简洁、高效且易于维护的解决方案。

       ZRAdmin.NET的前端技术栈基于Vue2.x或Vue3.x，辅以vuex、vue-router、vue-cli、axios、element-ui、vite、webpack、echarts和国际化插件in。通过使用Visual Studio Code作为开发工具，实现了代码的高效编写与管理。

       后端技术则专注于实现核心功能，优化了配置和依赖管理，旨在提供一个稳定、高性能的API服务。

       项目地址提供了一个直观的演示图，展示了其在实际应用中的功能与界面。如果您觉得ZRAdmin.NET在开发过程中对您有所帮助，请给予支持，通过在GitHub上Star该项目，以示鼓励。

.NET ORM 跨服库查询 MySql、Oracle、项目源码是怎么读SqlServer等相互联表

       SqlSugar ORM 的发展与重构

       在年，SqlSugar ORM经历了一年半的停更，主要是因为底层架构的影响，导致了技术上的瓶颈和遗留问题的累积。团队选择在那段时间内不进行更新，以避免对现有用户产生不必要的影响。这期间，团队努力保持与用户的沟通，鼓励那些热爱SqlSugar的用户寻找其他框架，同时留下了一批对SqlSugar有深厚情谊，愿意共同完善框架的用户。

       经过一年半的筹备，SqlSugar ORM在年正式开始重构，每过一个月就进行一部分的更新，并添加新的功能。最终，在大量努力和优化后，重构工作得以完成。现在，SqlSugar ORM可以实现多库架构，底层兼容性增强，例如事务处理无需引用外部DLL，底层语法支持多库操作。

       SqlSugar ORM支持跨服务器、跨库联表查询，并提供了一整套实现方式，包括一对一、一对多、蚂蚁面试源码怎么找多对多等查询模式。通过特性实现多库查询，或手动指定数据库进行查询，以满足不同场景的需求。

       重构后的SqlSugar ORM在性能方面同样得到保障，无论是单库查询还是多库查询，其性能一致，因为使用了一套统一的算法。其原理在于一次性获取所需数据，然后在内存中分配置，以便进行高效的数据读取。

       如今，SqlSugar ORM取得了显著的成绩。在企业认可方面，job使用SqlSugar ORM来搜索简历，其数量仅次于EF和Dapper，甚至超过了国外的Nhibernate和PetaPoco，占Dapper使用量的%。知名收费框架JNPF和力软都选择了SqlSugar作为其工具。同时，一些培训机构也开始将SqlSugar作为教学内容之一。

       在用户认可方面，SqlSugar ORM拥有强大的生态系统，据统计，有超过个项目的使用量，其中大多数项目在GitHub或Gitee上有星以上。此外，还有5个人规模的社区在讨论SqlSugar相关的内容。一些知名项目如RuYiAdmin、ZrAdminNetCore、Admin.NET通用管理平台、Yi框架（Ruoyi Vue）、CoreShop商城、Blog.Core等都在积极使用SqlSugar ORM。

       如需了解详细信息或寻求合作，欢迎访问SqlSugar的官方GitHub仓库，获取源码或参与讨论。

.NET Core 实现基于Websocket的在线聊天室

       Websocket是解决Web实时通讯问题的一种技术，它在没有被发明前，人们通常使用HTTP长轮询（Long Polling）技术。这种技术虽然能实现双工通讯，但存在大量头部数据传输的浪费和服务器资源消耗的问题。WebSocket的出现很好地解决了这一问题，它基于TCP协议重新设计了一套协议，同时兼容HTTP，使用默认的/端口。建立WebSocket链接实质上就是一次HTTP请求，通过HTTP协议的upgrade头标识为WebSocket请求，服务器端回复状态码表示成功握手。

       在使用ASP.NET Core处理WebSocket时，首先需要新建一个ASP.NET Core网站并创建WebsocketHandlerMiddleware中间件。这个中间件是管理WebSocket链接的入口，调用context.WebSockets.AcceptWebSocketAsync()方法将请求转换为WebSocket链接。在Invoke方法中接收WebSocket链接，在Handle方法等待客户端的消息，通过MessageRoute方法对客户端的消息进行转发。

       为了实现WebSocket链接和消息处理，还需要新建一个WebsocketClientCollection管理类来存放所有的WebSocket链接，以便统一管理。在Startup中使用中间件后，服务端基本搭建完成。

       接下来，编写客户端HTML和JavaScript以实现聊天室界面。修改index.cshtml文件创建简单的聊天室UI，使用JavaScript操作WebSocket对象来建立和处理连接及消息。现代浏览器已经内置WebSocket支持，通过new WebSocket对象即可进行操作。

       搭建完成后，运行聊天室效果。启动两个页面进行聊天，可以看到消息实时转发，这证明了聊天室成功搭建。源码已上传至GitHub（CoreWebsocketChatRoom），欢迎查看。

.NET core扫盲

       .NET发行至今已经过了十四个年头。随着版本的不断迭代更新，.NET在Windows平台上的表现也是越来越好，可以说Windows平台上所有的应用类型.NET几乎都能完成。只是成也Windows，败也Windows，这十四年来，除了部分“民间”版本，.NET一直没能在官方支持下摆脱Windows平台的局限，“开源”和“跨平台”这两个词语也是所有.NET开发者心中的痛楚。最终，.NET Core出现了，它让开发者们在官方和社区的支持走出了Windows，可以在macOS，Linux主流distributions上编写调试并部署.NET程序。

       .NET Core是一个开源通用的开发框架，支持跨平台，即支持在Window，macOS，Linux等系统上的开发和部署，并且可以在硬件设备，云服务，和嵌入式/物联网方案中进行使用。.NET Core的源码放在 GitHub上，由微软官方和社区共同支持。它和传统的.NET Framework，属于“子集—超集”的关系，或者你也可以简单地认为它就是.NET Framework的跨平台版本（基于 BCL的层面上看）。这是因为在当前版本中（1.0），.NET Core中的大部分核心代码都是从.NET Framework中继承重写的，包括Runtime和Libraries（如GC, JIT, 部分类型）。

       现在的.NET Core 1.0版本是一个很小的核心，APIs和工具也并不完整，但是随着.Net Core的不断完善，补充的Apis和创新也会一起整合到.NET Framework中。也就是说，.NET Core微软会同时更新.NET Framework和.NET Core，他们就像俩兄弟，共同努力致富（致谁的富？当然是.NET开发者们），实现所谓的天下大同，也就是 .NET 标准2.0

       这里不得不提到一个叫做 .NET Standard Library概念。作为.NET平台APIs开发官方支持标准，它要求所有的.NET框架APIs都遵循向下兼容。比如说.NET Framwork 4.6支持.NET Standard Library 1.3，.NET Framwork 4.6.2框架支持.NET Standard Library 1.5，而.NET Core 1.0框架支持1.6标准。

       Tips:是不是想起了MSCorEE.dll这个垫片，它同样承载着Windows平台上为.NET应用程序选择CLR版本的工作

       第二种方式和.NET Native也是不一样的，仍然使用CoreCLR，而.NET Native使用CoreRT作为运行时，详细信息请见 dotnet/corert

       .NET Core 1.0版本中支持的编程语言仅有C#（F#和VB暂未实现），这里还要提到一个开源的语言编译器Roslyn，它负责将代码编译成我们熟悉的IL语言，然后再借由AOT或JIT编译器编译成机器熟悉的机器语言。

       以下内容演示在Windows和CentOS 7.2下的命令行生成和发布demo

       3.1 Win

       3.1.1 安装 .NET Core SDK和 .NET Core Runtime .NET Core SDK = 使用.NET Core开发应用.NET Core Runtime 和 SDK+CLI 工具

       3.1.2 简单的运行结果 打开cmd，依次输入mkdir .project（创建目录），cd .\.project（进入目录），dotnet new（新建初始项目），dotnet restore（还原依赖），dotnet run（运行）即可运行第一个Hello World程序

       3.2 CentOS 7.2（本地Hyper-V）

       3.2.1 安装和运行 详情请见： .NET Core in CentOS，大致命令如下

       第六行命令后可使用dotnet --info查看是否链接成功，显示如下

       以上步骤在.NET Core官方网站都可以找到，可以看到应用在经过简单的dotnet new, dotnet restore, dotnet run命令后就跑起来了，但是这其实是类似于开发环境中的调试运行，而且win上new的应用此时也不能直接跨平台到Linux下运行，所以我们又得提到dotnet publish命令了

       3.2.2 Self-contained applications 发布 （1） 修改project.json文件 我们现在win下按照步骤new一个新的HW控制台应用self，按照 官方文档要求，我们需要用以下内容替换原来project.json文件（删除"type": "platform",并增加runtimes节点）

       （2） 执行restore和publish操作

       之后执行dotnet restore指令，针对平台进行还原操作。该步操作耗时较久，虽然只是两个平台，第一次也花了较长时间。紧接着进行进行dotnet publish -r centos.7-x -c release。

       dotnet publish指令详见 dotnet-publish - Packs the application and all of its dependencies into a folder getting it ready for publishing （3） 在Linux平台上运行

       上述操作后，我们只需要将发布后的文件夹（bin/release/netcoreapp1.0/centos7-x/publish，包含self.exe）上传到Linux root目录下project（新建）文件夹中， 在Shell中输入指令

       修改可执行权限后，即可成功运行“Hello World”，这就是我们“Self-contained applications”方式的部署方法

       至此，.NET Core的学习便告一段落了，以上内容简单介绍了.NET Core的组成和特性，同时也在Windows和Linux系统上通过两种不同的部署方式成功运行了示例。相比较之前的.NET Framework傻瓜式部署，.NET Core的新奇真是让我眼前一亮。接下来，我也会将.NET Core和 ASP.NET Core的学习记录下来，欢迎指正。

       4.2 相关学习资料

       5. 参考资料

ASP.NET Core认证原理和实现

       é€šå¸¸åœ¨åº”用程序中，安全分为前后两个步骤：验证和授权。验证负责检查当前请求者的身份，而授权则根据上一步得到的身份决定当前请求者是否能够访问期望的资源。

        既然安全从验证开始，我们也就从验证开始介绍安全。

        我们先从比较简单的场景开始考虑，例如在 Web API 开发中，需要验证请求方是否提供了安全令牌，安全令牌是否有效。如果无效，那么 API 端应该拒绝提供服务。在命名空间 Microsoft.AspNetCore.Authentication 下，定义关于验证的核心接口。对应的程序集是 Microsoft.AspNetCore.Authentication.Abstractions.dll。

        在 ASP.NET 下，验证中包含 3 个基本操作：

        验证操作负责基于当前请求的上下文，使用来自请求中的信息，例如请求头、Cookie 等等来构造用户标识。构建的结果是一个 AuthenticateResult 对象，它指示了验证是否成功，如果成功的话，用户标识将可以在验证票据中找到。

        常见的验证包括：

        在授权管理阶段，如果用户没有得到验证，但所期望访问的资源要求必须得到验证的时候，授权服务会发出质询。例如，当匿名用户访问受限资源的时候，或者当用户点击登录链接的时候。授权服务会通过质询来相应用户。

        例如

        质询操作应该让用户知道应该使用何种验证机制来访问请求的资源。

        在授权管理阶段，如果用户已经通过了验证，但是对于其访问的资源并没有得到许可，此时会使用拒绝操作。

        例如：

        拒绝访问处理应该让用户知道：

        在这个场景下，可以看到，验证需要提供的基本功能就包括了验证和验证失败后的拒绝服务两个操作。在 ASP.NET Core 中，验证被称为 Authenticate，拒绝被称为 Forbid。 在供消费者访问的网站上，如果我们希望在验证失败后，不是像 API 一样直接返回一个错误页面，而是将用户导航到登录页面，那么，就还需要增加一个操作，这个操作的本质是希望用户再次提供安全凭据，在 ASP.NET Core 中，这个操作被称为 Challenge。这 3 个操作结合在一起，就是验证最基本的要求，以接口形式表示，就是 IAuthenticationHandler 接口，如下所示：

        验证的结果是一个 AuthenticateResult 对象。值得注意的是，它还提供了一个静态方法 NoResult() 用来返回没有得到结果，静态方法 Fail() 生成一个表示验证异常的结果，而 Success() 成功则需要提供验证票据。

        通过验证之后，会返回一个包含了请求者票据的验证结果。

        在 GitHub 中查看 AuthenticateResult 源码

        那么验证的信息来自哪里呢？除了前面介绍的 3 个操作之外，还要求一个初始化的操作 Initialize，通过这个方法来提供当前请求的上下文信息。

        在 GitHub 中查看 IAuthenticationHandler 定义

        有的时候，我们还希望提供登出操作，增加登出操作的接口被称为 IAuthenticationSignOutHandler。

        在 GitHub 中查看 IAuthenticationSignOutHandler 源码

        在登出的基础上，如果还希望提供登录操作，那么就是 IAuthenticationSignInHandler 接口。

        在 GitHub 中查看 IAuthenticationSignInHandler 源码

        直接实现接口还是比较麻烦的，在命名空间 Microsoft.AspNetCore.Authentication 下，微软提供了抽象基类 AuthenticationHandler 以方便验证控制器的开发，其它控制器可以从该控制器派生，以取得其提供的服务。

        通过类的定义可以看到，它使用了泛型。每个控制器应该有一个对应该控制器的配置选项，通过泛型来指定验证处理器所使用的配置类型，在构造函数中，可以看到它被用于获取对应的配置选项对象。

        在 GitHub 中查看 AuthenticationHandler 源码

        通过 InitializeAsync()，验证处理器可以获得当前请求的上下文对象 HttpContext。

        最终，作为抽象类的 ，希望派生类来完成这个验证任务，抽象方法 HandleAuthenticateAsync() 提供了扩展点。

        验证的结果是一个 AuthenticateResult。

        而拒绝服务则简单的多，直接在这个抽象基类中提供了默认实现。直接返回 HTTP 。

        剩下的一个也一样，提供了默认实现。直接返回 HTTP 响应。

        对于 JWT 来说，并不涉及到登入和登出，所以它需要从实现 IAuthenticationHandler 接口的抽象基类 AuthenticationHandler 派生出来即可。从 AuthenticationHandler 派生出来的 JwtBearerHandler 实现基于自己的配置选项 JwtBearerOptions。所以该类定义就变得如下所示，而构造函数显然配合了抽象基类的要求。

        在 GitHub 中查看 JwtBearerHandler 源码

        真正的验证则在 HandleAuthenticateAsync() 中实现。下面的代码是不是就很熟悉了，从请求头中获取附带的 JWT 访问令牌，然后验证该令牌的有效性，核心代码如下所示。

        在 GitHub 中查看 JwtBearerHandler 源码

        在 ASP.NET Core 中，你可以使用各种验证处理器，并不仅仅只能使用一个，验证控制器需要一个名称，它被看作该验证模式 Schema 的名称。Jwt 验证模式的默认名称就是 "Bearer"，通过字符串常量 JwtBearerDefaults.AuthenticationScheme 定义。

        在 GitHub 中查看 JwtBearerDefaults 源码

        最终通过 AuthenticationBuilder 的扩展方法 AddJwtBearer() 将 Jwt 验证控制器注册到依赖注入的容器中。

        在 GitHub 中查看 JwtBearerExtensions 扩展方法源码

        一种验证处理器，加上对应的验证配置选项，我们再为它起一个名字，组合起来就成为一种验证架构 Schema。在 ASP.NET Core 中，可以注册多种验证架构。例如，授权策略可以使用架构的名称来指定所使用的验证架构来使用特定的验证方式。在配置验证的时候，通常设置默认的验证架构。当没有指定验证架构的时候，就会使用默认架构进行处理。

        还可以

        注册的验证模式，最终变成 AuthenticationScheme，注册到依赖注入服务中。

        在 GitHub 中查看 AuthenticationScheme 源码

        各种验证架构被保存到一个 IAuthenticationSchemeProvider 中。

        在 GitHub 中查看 IAuthenticationSchemeProvider 源码

        最终的使用是通过 IAuthenticationHandlerProvider 来实现的，通过一个验证模式的字符串名称，可以取得所对应的验证控制器。

        在 GitHub 中查看 IAuthenticationHandlerProvider 源码

        它的默认实现是 AuthenticationHandlerProvider，源码并不复杂。

        在 GitHub 中查看 AuthenticationHandlerProvider 源码

        验证中间件的处理就没有那么复杂了。

        找到默认的验证模式，使用默认验证模式的名称取得对应的验证处理器，如果验证成功的话，把当前请求用户的主体放到当前请求上下文的 User 上。

        里面还有一段特别的代码，用来找出哪些验证处理器实现了 IAuthenticationHandlerProvider，并依次调用它们，看看是否需要提取终止请求处理过程。

        在 GitHub 中查看 AuthenticationMiddle 源码