nuget

ViewFaceCore 0.2 超简单的 C# 人脸识别库 前言： 首先谢谢大家对这个库的关注，前一篇博文得到了大家的 支持 和 Star ，十分开心。本想尽快实现大家的期待的活体检测功能，但是前段时间太忙了，是在抱歉！！！ ⭐、GitHub & Important 本次更新的内容在 antispoofing 分支 上。 活体检测需要 fas_first.csta 、 fas_second.csta 两个模型 为方便使用，这两个模型也被包含在 Nuget 包中，0.2.x 版本在 70M+ 的大小 如果没有需要活体检测的需要，请继续使用 0.1.x 版本 0.2.x 版本将继续添加新的功能，也会继续包含必须的模型文件 0.1.x 版本将保持现有功能，并进行 bug 修复等工作 0.2.x 源代码在 antispoofing 分支 0.1.x 源代码在 master 分支 一、ViewFaceCore 介绍 这是基于 SeetaFace6 人脸识别开发的 .NET 平台下的人脸识别库 这是一个基于 .NET Standard 2.0 开发的库 这个库已经发布到 NuGet ，你可以一键集成到你的项目 更多请参见 C# 人脸识别库 。 二、更新 本次更新内容 添加了 活体检测 相关的方法 修复了识别结果部分未判断的 bug 修改了部分结构 更新后无需修改之前的代码。 三、使用 1.

在 2017 我在社区问了一个问题，如何让 .NET Framework 的 WPF 等程序使用 .NET Native 构建以提升速度。在 2019.06 的时候，强大的微软提供了一个好用的库，支持将 .NET Framework 的桌面应用构建时添加 native images 本机映像支持 咱可以通过预编译咱的二进制文件来提升 .NET Framework 应用的启动时间。推荐使用技术用来在大型的应用的打包和分发上或上架到微软应用商店。微软官方测试表示这个技术大概能提升 20% 的性能。这项技术用到了 ReadyToRun 技术，详细请看 coreclr/readytorun-overview.md at master · dotnet/coreclr 微软将这个本机映像编译器作为一个 NuGet 库发布，可以从 https://www.nuget.org/packages/Microsoft.DotNet.Framework.NativeImageCompiler 下载。这个库适用于 .NET Framework 大于等于 4.6.2 的应用。这个包的作用是在构建时添加一个步骤，这个步骤的作用是构建本机映像二进制文件。这个优化将会在应用在安装了 .NET Framework 4.7.2 和以上的设备运行时被使用，而之前的版本的设备将继续使用 MSIL 代码执行，换句话说

一.前言 这是《Blazor 修仙之旅》的第三篇，前面两分别是《初次尝试》、《组件与数据绑定》，直接到这里上 Ant Design 确实连不起来，跨度比较大，其实我也是在边学边写，看的是官方文档，我觉得中间这部分重复写博客的意义不大，所以我建议去看官方文档，传送门： 点我 。如果看过我的前两篇，我建议您从这里开始看： 点我 。不用每篇都深刻理解，但需要有一个基本概念。好了，下面进入正题。 二. Ant Design of Blazor 介绍 ant-design-blazor 是国内开发者 ElderJames 创建的一个开源项目。在前不久的微软Build大会也见到了它的身影，受到了微软官方推荐，点赞！顾名思义， ant-design-blazor 是 Ant Design 的 Blazor 实现，开发和服务于企业级后台产品。 ✨ 特性 🌈 提炼自企业级中后台产品的交互语言和视觉风格。 📦 开箱即用的高质量 Razor 组件，可在多种托管方式共享。 💕 支持基于 WebAssembly 的客户端和基于 SignalR 的服务端 UI 事件交互。 🎨 支持渐进式 Web 应用（PWA） 🛡 使用 C# 构建，多范式静态语言带来高效的开发体验。 ⚙️ 基于 .NET Standard 2.1，可直接引用丰富的 .NET 类库。 🎁 可与已有的 ASP.NET Core MVC

一个月前，公司的运行WCF的windows服务器down掉了，由于 AWS 没有通知，没有能 第一时间 发现问题。 所以，客户提出将WCF服务由C#改为JAVA，在Linux上面运行；一方面，AWS对Linux有较多的监控措施，另一方面，假如出现问题，可以设置自动重启等服务。 老旧的WCF服务 目前WCF服务，主要提供windows桌面软件的 数据接口 ，应该有五六年的历史了。我进入公司后，WCF服务的代码，一直由我一个人来维护。存在很多 历史遗留问题 ，也有 不同版本 的共存。 如果java重写的话，其中的业务逻辑代码，难免会出现各种各样的bug，增加开发和测试的工作量。听说，要移植到linux服务上后，第一时间想到的就是 跨平台 的 .net core 。 .net core 经过了四年的发展，到目前的 3.1 LST版本，已经是 非常成熟 的跨平台解决方案了。 之后，我就在网上查找，有没有WCF的.net core 版本，查询到的信息总结如下： Core WCF不打算做WCF到.NET Core的100％兼容的移植； 对于新应用程序，WCF这种SOAP技术不建议使用； 对于老的应用程序，建议将这些保留在.NET Framework上； 如果您真的想将一个旧的应用程序迁移到.NET Core并且想继续使用WCF和WF， 社区的开源项目也是可以的

本文3.0版本文章 https://mp.weixin.qq.com/s/pjvleNGi_AazZ7COdxQyPQ Redis 部分的内容，和netcore2.0一样，不需要更新。 代码已上传Github+Gitee，文末有地址 　　书说上文《 从壹开始前后端分离【 .NET Core2.0 Api + Vue 2.0 + AOP + 分布式】框架之十 || AOP面向切面编程浅解析：简单日志记录 + 服务切面缓存 》，昨天咱们说到了AOP面向切面编程，简单的举出了两个栗子，不知道大家有什么想法呢，不知道是否与传统的缓存的使用有做对比了么？ 　　传统的缓存是在Controller中，将获取到的数据手动处理，然后当另一个controller中又使用的时候，还是Get，Set相关操作，当然如果小项目，有两三个缓存还好，如果是特别多的接口调用，面向Service服务层还是很有必要的，不需要额外写多余代码，只需要正常调取Service层的接口就行，AOP结合Autofac注入，会自动的查找，然后返回数据，不继续往下走Repository仓储了。 　　昨天我发布文章后，有一个网友提出了一个问题，他想的很好，就是如果面向到了Service层，那BaseService中的CURD等基本方法都被注入了，这样会造成太多的代理类，不仅没有必要，甚至还有问题，比如把Update也缓存了

一个月前，公司的运行WCF的windows服务器down掉了，由于 AWS 没有通知，没有能 第一时间 发现问题。 所以，客户提出将WCF服务由C#改为JAVA，在Linux上面运行；一方面，AWS对Linux有较多的监控措施，另一方面，假如出现问题，可以设置自动重启等服务。 老旧的WCF服务 目前WCF服务，主要提供windows桌面软件的 数据接口 ，应该有五六年的历史了。我进入公司后，WCF服务的代码，一直由我一个人来维护。存在很多 历史遗留问题 ，也有 不同版本 的共存。 如果java重写的话，其中的业务逻辑代码，难免会出现各种各样的bug，增加开发和测试的工作量。听说，要移植到linux服务上后，第一时间想到的就是 跨平台 的 .net core 。 .net core 经过了四年的发展，到目前的 3.1 LST版本，已经是 非常成熟 的跨平台解决方案了。 之后，我就在网上查找，有没有WCF的.net core 版本，查询到的信息总结如下： Core WCF不打算做WCF到.NET Core的100％兼容的移植； 对于新应用程序，WCF这种SOAP技术不建议使用； 对于老的应用程序，建议将这些保留在.NET Framework上； 如果您真的想将一个旧的应用程序迁移到.NET Core并且想继续使用WCF和WF， 社区的开源项目也是可以的

最近GRPC很火，感觉整RPC不用GRPC都快跟不上时髦了。 gRPC设计 gRPC是一种与语言无关的高性能远程过程调用 (RPC) 框架。刚好需要使用一个的RPC应用系统，自然而然就盯上了它，但是它真能够解决所有问题吗？不见得，先看看他的优点： gRPC的主要优点： 现代高性能轻量级 RPC 框架。 协定优先 API 开发，默认使用协议缓冲区，允许与语言无关的实现。 可用于多种语言的工具，以生成强类型服务器和客户端。 支持客户端、服务器和双向流式处理调用。 使用 Protobuf 二进制序列化减少对网络的使用。 对应的适用场景： 微服务 ：gRPC 设计用于低延迟和高吞吐量通信。 gRPC 对于效率至关重要的轻量级微服务非常有用。 点对点实时通信 ：gRPC 对双向流式传输提供出色的支持。 gRPC 服务可以实时推送消息而无需轮询。 多语言环境 ：gRPC 工具支持所有常用的开发语言，因此，gRPC 是多语言环境的理想选择。 网络受限环境 ：gRPC 消息使用 Protobuf（一种轻量级消息格式）进行序列化。 gRPC 消息始终小于等效的 JSON 消息。 gRPC还是有缺点的： 浏览器支持受限 ：绝大数浏览器不支持 HTTP/2 非人工可读取 ：proto文件规定的格式在通讯中会序列化成二进制数据，人工解析较为困难。 不适用的场景与替代： 浏览器可访问的API ：gRPC

在上一篇博客告诉小伙伴如何使用 github 做持续集成，本文告诉大家如何配置 github 让在 master 每次合并都会自动创建一个 nuget 文件，自动上传 在 github 的 action 功能可以很方便创建打包任务，但是没有很方便进行 nuget 上传，需要额外写一点代码 全部的源代码请看 github 如果发现有坑请邮件告诉我 创建配置文件 在 上一篇 博客告诉小伙伴在 .github/workflows 文件夹创建 *.yml 文件就可以作为 action 配置文件 创建一个随意命名的 yml 文件在 .github/workflows 文件夹，完成创建配置文件 标识 每个 workflow 都可以使用单独的命名，这个命名不是从文件名读取，而是通过 name: 属性读取。在读本文之前，我认为小伙伴都是了解 YAML 格式的，也就不对大家说明 YAML 的语法 name: publish nuget 上面的代码就会添加命名是 publish nuget 的 workflow 在 action 页面可以通过对应的命名找到不同的 workflow 如 触发条件 因为我不需要在任何的分支都触发打包，只需要触发在 master 合并，可以使用下面代码 on: push: branches: - master 这里 on 属性就是表示触发条件，触发条件是 push

原文: 【无私分享：ASP.NET CORE 项目实战（第八章）】读取配置文件（二） 读取自定义配置文件 目录索引 　 【无私分享：ASP.NET CORE 项目实战】目录索引 简介 　　我们在 读取配置文件（一） appsettings.json 中介绍了，如何读取appsettings.json. 　　但随之产生了问题：我们使用的是在 Startup.cs 中（如下图）来实现配置读取，有两个问题 ① 我们如果定义N种配置，是否要再这里添加N条这样的配置 ； ② 如果我们的配置不想写在appsettings.json中呢 　　 　　 解决问题 　 带着上面的两个问题，我们首先来添加一个配置文件 siteconfig.json 　　 　　{ 　　　　"SiteBaseConfig": { 　　　　　　//文件上传路径 　　　　　　"FileUpPath": "/upload/", 　　　　　　//是否启用单用户登录 　　　　　　"IsSingleLogin": "True", 　　　　　　//允许上传的文件格式 　　　　　　"AttachExtension": "gif,jpg,jpeg,png,bmp,rar,zip,doc,docx,xls,xlsx,ppt,pptx,txt,flv,apk,mp4,mpg,ts,mpeg,mp3,bak,pdf", 　　　　　　/

我在团队内的几乎所有 dotnet 项目，包括 UWP 和 WPF 桌面端以及 Xamarin 移动端和 ASP.NET Core 后端等需要用到多语言的项目，我的多语言都是通过 YAML 写的，这样相对来说在项目比较小的时候维护方便。但是 YAML 写的文件要读取需要用到 YAML 解析等，这部分的解析速度不够快，于是我就写了一个工具，用于在软件构建的时候自动将 YAML 多语言文件构建为代码。这样不仅能提升软件的执行速度，还能减少软件发布时需要带出去 YAML 解析库 用 YAML 做多语言有什么好处？其实在项目用的语言项不多的时候可读性还是很好的，维护起来也很清真 但是用 YAML 作为输出的缺点是需要在软件运行的时候解析这个 YAML 多语言文件，而解析 YAML 多语言文件需要 YAML 解析库，但是实际上我可以在软件构建的时候将 YAML 文件转换为 C# 代码，这样我就可以在软件运行的时候不需要解析这个 YAML 文件，提升我软件的运行速度 在客户端的应用，很多时候在软件运行第一个界面就需要用到多语言，而启动的时候文件读写最多的。如果此时还需要读取 YAML 文件，那么对软件启动速度还是很伤的。而刚好 dotnet 的一项技术就是 Roslyn 预编译技术，虽然本文用到的技术和 Roslyn 没有什么关系。但是可以在软件构建的时候将 YAML 转 C#