开发现代化的.NetCore控制台程序:(1)项目介绍以及依赖注入/配置/日志等使用细节
开发.NET Core控制台工具,依赖注入和日志整合得比Go优雅多了。哼,配置文件丝滑,但AOT?反射问题,放弃。
STARBLOG / 技术与日常的文字存档
写下实践中的发现,也留住那些值得回看的想法。
开发.NET Core控制台工具,依赖注入和日志整合得比Go优雅多了。哼,配置文件丝滑,但AOT?反射问题,放弃。
又一个.NetCore模板?FluentConsole.Templates,一键生成骨架,包含DI、日志、配置。安装?dotnet new install,然后dotnet new flu-cli -n MyProject。太简单了吧,谁在乎?
作者弃bash、Python、C#,选Go写Hive导出工具,只因部署简单。Go的err处理烦人,但交叉编译省事。工具交互式,搞定导出。
EFCore居然没有内置命名转换?得自己写正则或用插件,真是折腾。插件一行代码搞定,但为什么EFCore不直接支持?命名风格转换,要么自己写代码,要么依赖第三方,真费劲。
很多项目一开始选型的时候没有选择EFCore,不过EFCore确实好用,也许由于种种原因后面还是需要用到,这时候引入EFCore也很方便。 本文以 StarBlog 为例,StarBlog 目前使用的 ORM 是 FreeSQL ,引入 EFCore 对我来说最大的好处是支持多个数据库,如果是 FreeSQL 的话,服务注册的时候是单例模式,只能连接一个数据库,如果需要使用 FreeSQL 同时
Docker部署RedisStack?呵,基础操作罢了。ACL权限?不过是Redis 6.0的标配功能。C#集成?官方NRedisStack包,一行代码的事。
C#开发者用iKVM白嫖JVM生态?省事,但依赖处理还得手动折腾。无缝接入?不过是把JAR转DLL,省了移植代码的麻烦。AI工具缺?直接调用HanLP,但依赖处理,呵呵。
下载音乐防灰,工具链折腾值不值?搭建私有流媒体,客户端体验一般般。数据自主权在手,平台下架算什么?
人脸检测与识别现在已经很成熟了,C# 上有 ViewFaceCore 这个很方便的库,但这种涉及到 native 调用的库,一般会有一些坑,本文记录一下开发和部署的过程。
之前我写过一篇使用 docker 部署 AspNetCore 应用的文章,这种方式搭配 CICD 非常方便, build 之后 push 到私有的 dockerhub ,在生产服务器上 pull 下来镜像就可以直接运行了。 然而,有时需要一种更传统的部署方式,比如在本地打包可执行文件之后直接放到服务器上执行。 这种方式配置完成之后,每次更新只需要重新本地重新 publish 后把可执行文件上传
我在使用 AspNetCore 的这段时间内,看了很多开源项目和博客,发现各种 .Net 体系的新技术很多人都有关注和使用,但却很少有人关注测试。 测试是软件生命周期中的一个非常重要的阶段,对于保证软件的可靠性具有极其重要的意义。在应用程序的开发过程中,为了确保它的功能与预期一致,必须对其进行测试。这样做不仅能够确保功能正确执行,同时能够帮助开发人员尽早地发现并改正系统中所存在的缺陷(Bug),
Vue 可以非常方便地与 Pure HTML 结合,代替 jQuery 的功能,有一次遇到类似的场景时,我就想 React 能不能也以这种方式接入 HTML 网页,从而提高开发效率。 结果当然是可以的,只不过在 HTML 里直接 JSX 似乎会降低一些性能… 凑合用吧