距离微软正式发布.NET 8.0已经有一段时间，这也是新的LTS（长期技术支持）版本，这个版本更新了多个新的特性，并且提升了性能，似乎每一代框架发布总是能比上一代提升不少性能。近期抽空将本网站平台适配到了.NET 8.0，暂时没有发现什么Breaking Changes，一切很平滑，除了升级到.NET 8.0外，还对以下特性进行了修改： 1. 软件层面 1.1 验证码模块 验证码（CAPTCHA）又称全自动区分计算机和人类的图灵测试，之前本站验证码使用了两套：一套是Edi Wang开发的图形化验证码，主要用在评论发布页面；另一套是Google的reCAPTCHA，主要用在联系表单。但是这两套验证码都存在问题，其中Edi Wang的图形验证码使用了传统的数字字母图片，为了避免OCR还加了变形扭曲，在Web 2.0兴起的年代，这种方法足够抗击机器人和爬虫的不法攻击，随着人工打码平台和 …

博客一直使用谷歌分析（Google Analytics）作为流量统计分析平台，随着大家对隐私的重视，尤其是欧洲通用数据保护条例（GDPR）的颁布，谷歌分析的使用就有必要征求用户的同意，本博客自改版之后在隐私条款处已经说明使用了谷歌分析，并且在Cookie设置处也将允许谷歌分析的权限交给用户，经过一年多的运行发现存在相应的问题，最主要的是如果本博客访问的用户不设置Cookie，这也是大多数情况，一般博客右下角的Cookie提醒是可以忽略的，那么统计必然不准确，那么谷歌分析就失去了参考价值，好在由于全站套用了Cloudflare CDN，其中Cloudflare基础版（Free Plan）提供了一个简单的流量分析模块，让自己也大概能够窥探自己博客的流量情况。 为了能够更好的得到博客热门文章、访问者设备类型、设备分辨率这些信息以供以后改进博客内容和用户体验，同时兼顾用户隐私，决定尝试使用 …

互联网上有很多关于IE（Internet Explorer）的梗，确实IE已经是一款很老的浏览器了，刚才我打开Windows 10自带的IE，除了推荐我使用Edge外也在明示IE将在6月正式退役，所以现在开发的网站基本也不会在考虑IE，同样的考虑到本站的访客大部分应该是有一定技术背景的，用IE的可能性也不大，所以网站也不兼容IE，尤其是淘汰了TLS 1.1加密套件后，基本上也就目前最高版本的IE还能打开，我也稍微调整了一下JavaScript和CSS，让IE勉强可以浏览内容，但是交互的部分就无法保证了，等IE彻底退役后将不再考虑IE的可访问性。 实际上对于类似IE这类老旧浏览器最大的问题就是新的前端特性支持不全，导致脚本报错，除了可以使用jQuery替代外，也能使用一些Polyfill进行对应的Hack，其实随着新的前端技术的引入，我们对于jQuery的依赖越来越小，以后大的方向应该是抛弃 …

本网站自从3月上线以来已经有8个月时间，期间也有各种bug，也勉强修复了，最初网站运行在.NET 5.0平台上，后来一直关注着.NET 6.0的进展，在微软正式Release的时候立马开始适配新的6.0平台，期间也遇到过各种坑，留有这篇文章仅做记载。 1 安装Visual Studio 2022 因为Visual Studio 2019不再支持NET 6.0 SDK，如果想继续在VS平台下开发，必须升级到Visual Studio 2022，对于个人来说我们选择Community版本就可以了，安装完成后选择用最新的VS2022打开你的项目。 2 升级NuGet Package到最新版本 由于我是等到.NET 6.0正式版出来的时候升级的，大部分的第三方包（Package）已经适配了.NET 6.0，可以直接升级，但仍然建议各位查阅项目官方的文档，特别是breaking changes以及用 …

.NET Core多语言本地化支持可以让所开发的应用更加国际化，但是不同操作系统平台之间可能会遇到一些特有的部署问题，本文将介绍我在Linux环境下部署国际化应用过程中遇到的zh-CN中文资源丢失问题的解决方案，当然可能有其他更好的方案，这里不做推荐，本文操作使用的软件环境是Debian 11、ASP.NET 5.0、nginx，仅供参考。 1 多语言国际化应用的建立 .NET Core本地化方式参考《Globalization and localization in ASP.NET Core》，通常情况下，在Startup.cs的ConfigureServices部分会包含如下代码： services.AddLocalization(options => options.ResourcesPath = "Resources"); services.AddMvc() . …

大多数情况下我们开发的应用可能需要与其他服务进行交互，比如数据库服务、第三方服务等等，出于安全考虑，这些服务的交互都需要发起端提供认证凭据，这里可能是账号密码、API Key等，这里就涉及到认证凭据的保管问题，很长一段时间我们都是将认证凭据写死到配置文件中，这样做一开始是简单可行，但是随后你就会发现带来了一系列的问题：首先你的所有开发环境和生产环境都需要配置成一样的，比如生产环境数据库账号和密码和开发环境数据库账号和密码最好是一致的，否则部署到生产环境则需要手动修改这个认证凭据，当然你也可以通过配置分离或者环境变量控制来避免这个问题；其次是代码仓库提交，尤其是开源项目，至今GitHub公共库仍然存在大量配置文件明文保管着敏感凭据；最后分布式开发或者交付麻烦，需要团队合作或者直接提供给终端用户的项目，团队成员或者终端用户需要修改为本地环境凭据。 1 .NET Core与secrets. …