.NET Core

在WPF中保存控件内容为图片 实现代码如下 1 private void SaveControlContentAsImage(FrameworkElement element, string fileName) 2 { 3 var render = new RenderTargetBitmap(( int )element.ActualWidth, ( int )element.ActualHeight, 96 , 96 , PixelFormats.Default); 4 render.Render(element); 5 BitmapEncoder encoder = new JpegBitmapEncoder(); 6 // BmpBitmapEncoder 7 // GifBitmapEncoder 8 // PngBitmapEncoder 9 // TiffBitmapEncoder 10 11 encoder.Frames.Add(BitmapFrame.Create(render)); 12 using (System.IO.FileStream fs = System.IO.File.Create(fileName)) 13 { 14 encoder.Save(fs); 15 } 16 17 } 这里主要用到 RenderTargetBitmap 、

微服务确实是行业的一个趋势，我自己也在把一些项目往微服务架构迁移。玩微服务架构配置中心是一个绕不过去的东西，有很多大牌的可以选，比如spring-cloud-config，apoll，disconf等等。而我为什么还要造一个轮子呢？一来这些都不是.net实现的，我就想试试用.net core实现一个，而且他们也对.net不太友好，也只有apoll提供了官方的.net客户端。二来这些组件都太重量级了，比如apoll，光跑起来就要部署多个节点（admin,portal,meta sevice）还要依赖eureka。很多旧的项目往微服务迁移的时候并不是一下次全部调整完成的，可能是一步步来的，比如先把所有的服务都容器化，并没有使用微服务全家桶。而且有的项目也不需要微服务全家桶，毕竟微服务不是银弹，很多项目单体结构就足够了，有些项目传统的SOA架构也可以了。（唠叨一句，那种毫无流量毫无并发的项目，几人几天就搞完的强上微服务真的好吗？）但是这些项目也可能是分布式的，容器化部署的，那么这些项目我觉得也是需要配置中心的，因为在分布式、容器化环境下更改配置实在是太麻烦了。可以说配置中心并不是微服务独有的。基于以上原因我提炼了一些配置中心必备的功能，做的尽量简单（陋），开发了AgileConfig，为.net core的生态尽一份绵薄之力。 Github求star： AgileConfig

源码介绍： 　　海康摄像头web端无插件播放是指设置好摄像头参数后，即可在web浏览器不安装任何自定义插件即可实现流程播放。 　　系统通过拉取海康rtsp流，在用户点击观看时，自动将流转换为rtmp与hls流，推送到自定义流媒体服务器，实现web端 flash播放与html5原生播放。 如有需求，可在线留言或者发消息都可以，看到后会第一时间回复。 目前支持如下功能： 在线观看、摄像头转动调焦操作、视频录制、分屏播放等。 系统介绍： 使用web端播放无需插件（支持flash 与 html播放器 直接播放） 手机/微信端可以实时播放 rtsp流转rtmp,rtsp转hls 系统web端基于.net core 开发，推流、录制端基于.net 开发。 自动推流，无人观看时自动关闭推流 录制设置 提供第三方API，可单独部署作为单独应用使用，也可与任意第三方业务系统进行对接。 运行效果 来源： oschina 链接： https://my.oschina.net/u/4374904/blog/4496608

我写了一个有趣的工具，我如何将这个工具给到小伙伴予力众生呢？只需要设定这个工具是 dotnet tool 工具就可以通过 NuGet 分发出去啦。几乎所有的 dotnet 开发者都能用上 NuGet 服务，也就是此工具可以被几乎所有的 dotnet 开发者下载使用。那么制作难度有多大呢？基本上有一个现成的项目前提下，只需两句代码，一句命令行，就能完成制作 本文分为两部分，第一部分就是如何打包一个 dotnet tool 工具，第二部分是如何分发这个工具 在开始之前，我推荐你先安装好 VisualStudio 工具，在 VisualStudio 2019 的帮助下，能够快速简单进行打包和发布 如何打包 dotnet tool 工具 其实 dotnet tool 工具没有任何黑科技，原理就是用 dotnet tool install 命令，这个命令将会通过后续传入的包的 id 从 NuGet 上寻找这个工具，下载到本地。此时要求工具本身不需要做安装包等类似的部署，而是直接复制文件过来就能使用的工具 工具的前提要求就是，这个工具本身通过复制文件的形式就能在设备上运行，无需部署 而 NuGet 包的本质就是一个压缩包，将这个工具压缩，然后修改为 NuGet 包，上传到 NuGet 上，这样就支持其他人从 NuGet 上下载这个工具的压缩包。那么工具和其他库的包有什么不同

写在前面： 为了应对标准化和跨平台的趋势，更好的推广OPC，OPC基金会在OPCDA成功应用的基础上推出了一个新的OPC标准——OPC UA，OPCUA不再基于分布式组件对象模型（DCOM），而是以面向服务架构（SOA）为基础，因此，在未来的若干年中，OPCUA将逐步取代OPCDA，成为新一代的OPC标准，助力工业4.0。 而提起MQTT，或许大家有些陌生。MQTT是一个基于客户端-服务器的消息发布/订阅传输协议。具有轻量、简单、开放和易于实现的特点，尤其在物联网IOT领域应用非常广泛。 物联网一直都是一个很热门的话题，而数据上云，也是现在工业上很普遍的一个需求。至于如何实现，各个厂家都提供了各种不同的解决方案，无分好坏，最适合的就是最好的。 刚看完一篇名为《OPCUA+MQTT=物联网扩展的热门组合》的公众号文章之后，文思泉涌，想着如何将OPCUA与MQTT联合起来，构建一个物联网通用框架，实现数据远传。 整体网络架构 很多时候，我们的需求是这样的：现场有N台不同的设备或系统，每台设备或者系统的协议是各不相同的，希望可以用一种通用并且简单的方法，将这些数据传到云端，实现远程访问。 这样的需求，其实是物联网最典型的应用之一，那么采用OPCUA+MQTT或许是个不错的选择，整体的框架设计如下： 图表 1 整体网络架构 为了实现整体功能，这里的设备层，采用Modbus Slave

一个月前，公司的运行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， 社区的开源项目也是可以的

迁移.net framework的项目，有块读取txt中文转码的问题，普通的不能再普通的代码，想都没想直接copy过去，也没测，结果今天就被坑了。Core是3.1版本，这是原来的代码： string content = System.IO.File.ReadAllText(fileFullPath, Encoding.Default); System.IO.File.WriteAllText(fileFullPath, content, Encoding.UTF8); 很基础的功能，网上一搜一大堆。但是Core直接运行读取中文还是乱码，看似一个小问题，百度之，渐渐的发现这是一个小坑坑，于是乎，开始刨根问底。 首先发现两个环境下 Encoding.Default 这个东西是不同的。官方API解释： 链接 瞅瞅这是人话吗，为什么Core就始终返回utf8呢？看了一眼.net framework下的 Encoding.Default，是这个东东。 所以换个编码就应该就OK了（当然中文本来就是GB2312），结果现实啪啪打脸，居然报错了（脑补一个笑哭的表情）。 string content1 = System.IO.File.ReadAllText(filePath, Encoding.GetEncoding( " GB2312 " )); 官方API解释： Encoding

如果我使用的是具体的数组而我的数组是基类数组，而我传入子类的元素进行 json 序列化，可能发现 Json.NET 序列化没有包含子类元素的属性。如果要包含子类的属性或字段，可以在序列化的类数组定义为 object 数组的方式 我在用 WPF 写一个复杂的应用，我需要 ASP.NET Core 后台传输一个 AppData 类的数组，包含的属性如下 public class Lindexi { public string Name { set; get; } } 然后我有 Foo 类继承 Lindexi 类 public class Foo : Lindexi { public string F1 { set; get; } } 用下面代码序列化 static void Main(string[] args) { Console.WriteLine(ToString(new Foo() { F1 = "林德熙是逗比" })); } static string ToString(Lindexi lindexi) { return JsonSerializer.Serialize(new [] { lindexi }); } 运行可以看到输出 [{"Name":null}] 也就是 Foo 的属性被丢失了，在 .NET Core 3.0 可以使用 System.Text.Json

本文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也缓存了

上一篇文章( https://www.cnblogs.com/meowv/p/12909558.html )完善了项目中的代码，接入了Swagger。本篇主要使用Entity Framework Core完成对数据库的访问，以及使用Code-First的方式进行数据迁移，自动创建表结构。 数据访问 在 .EntityFrameworkCore 项目中添加我们的数据访问上下文对象 MeowvBlogDbContext ，继承自 AbpDbContext<T> 。然后重写 OnModelCreating 方法。 OnModelCreating ：定义EF Core 实体映射。先调用 base.OnModelCreating 让 abp 框架为我们实现基础映射，然后调用 builder.Configure() 扩展方法来配置应用程序的实体。当然也可以不用扩展，直接写在里面，这样一大坨显得不好看而已。 在abp框架中，可以使用 [ConnectionStringName] Attribute 为我们的DbContext配置连接字符串名称。先加上，然后再在 appsettings.json 中进行配置，因为之前集成了多个数据库，所以这里我们也配置多个连接字符串，与之对应。 本项目默认采用MySql，你可以选择任意你喜欢的。 //MeowvBlogDbContext.cs using