C# - Anduin Xue

29

JUL

Build a common cache service for your C# app.

这篇文章介绍了如何通过封装Microsoft.Extensions.Caching.Memory库创建一个更简洁的缓存抽象层，重点展示了CacheService类通过策略模式实现的条件缓存机制与选择器模式的结合应用。作者通过封装后的RunCache方法简化了复杂对象的缓存操作，允许开发者通过设置缓存过期时间动态控制数据新鲜度，并通过Selector模式实现缓存数据的转换处理。单元测试示例验证了该方案在不同场景下的行为特征：包括基于缓存条件的动态存储策略、对null值的特殊处理、通过选择器转换数据后的缓存逻辑，以及如何通过设置0分钟缓存时间实现强制刷新。这种设计既保持了原始缓存库的灵活性，又通过策略模式将缓存规则与业务逻辑解耦，为复杂缓存场景提供了可扩展的解决方案。测试用例的覆盖范围暗示着该模式在处理多条件组合缓存场景时的鲁棒性，同时引发思考：是否还有其他维度可以扩展这种缓存策略模式？--Qwen3

20

JUL

Restore a deleted branch from Azure DevOps using it's SDK

本文介绍了如何通过Azure DevOps SDK恢复被误删的代码分支的技术方案。文章指出当开发分支被删除后，可以通过Azure DevOps提供的Git API获取分支最后的提交记录，并利用Git引用更新机制重建分支。开发者需要先通过VssConnection建立认证连接，使用GitHttpClient获取分支的推送历史，找到被删除前的提交ID，再通过UpdateRefsAsync方法将分支引用重新指向该提交。这个过程涉及对Git底层引用机制的深入理解，包括如何处理旧对象ID与新对象ID的映射关系。代码示例展示了如何构建GitPushSearchCriteria查询参数，解析返回的RefUpdates数据，并构造GitRefUpdate请求体。特别值得注意的是，文章揭示了在更新引用时将OldObjectId设为全零占位符的技巧，这是实现分支恢复的关键技术点。技术实现过程中涉及的权限控制、项目名称与仓库ID的匹配等问题，为开发者提供了思考空间。当本地执行git fetch后，删除的分支会重新出现在版本历史中。这引发我们思考：如何在团队协作中设计分支保护策略？当多用户同时操作时，这种恢复机制是否具有原子性？如果在不同版本的Azure DevOps中执行该操作，可能会遇到哪些兼容性问题？--Qwen3

C# git Azure Azure DevOps SDK Git Branch Restore

20

MAY

Programmatically connect to the remote server via SSH and execute remote command.

文章围绕如何通过程序化方式实现SSH远程服务器连接与命令执行展开重点探讨了.NET Core环境下借助SSH.NET库完成自动化运维任务的实践路径。开发者通过创建控制台项目并集成SSH.NET库实现了从连接认证到命令执行的完整流程验证了使用代码替代人工SSH操作的可行性。示例代码展示了如何通过Renci.SshNet命名空间下的SshClient类构建连接执行"apt upgrade"命令并输出执行结果同时处理连接状态与错误信息。这种程序化方案为服务器管理工具开发提供了新思路但也引发关于自动化运维边界与风险的思考——当机器接管了原本需要人工判断的运维操作后如何确保指令执行的准确性如何处理敏感操作的认证安全如何应对网络波动导致的连接中断等问题。文章提供的代码框架虽然实现了基础功能但实际应用中可能需要更复杂的逻辑处理例如异步执行、结果解析、异常重试等机制的补充。SSH.NET作为支持并行操作的开源库其文档中提及的高级特性如端口转发、文件传输等功能是否能与现有代码形成更强大的组合如何构建可扩展的服务器管理架构这些都值得进一步探索。当代码开始远程操控物理服务器时我们是否正在见证运维工作的范式转移？自动化程度的提升是否会让服务器管理变得更加透明还是反而带来新的复杂性？这些问题或许能在文章提供的实践基础上找到启发性的答案。--Qwen3

C# .NET Core bash Linux SSH Renci.SshNet

01

APR

Use JetBrains code quality analyzer to prevent checking-in bad C# code

本文介绍了如何通过JetBrains ReSharper代码质量分析工具在Azure DevOps和GitHub Actions中自动拦截不符合规范的C#代码提交。文章展示了在持续集成流水线中集成ReSharper的YAML配置方案，包括安装代码质量分析插件、定义检查任务优先级以及通过.editorconfig文件自定义规则集的完整实践路径。特别指出在Azure DevOps中将代码检查任务置于构建之后测试之前可避免无效代码测试浪费资源，并揭示了无需购买ReSharper授权即可通过dotnet工具链实现本地代码质量检测的免费方案。文章引发思考：当自动化代码检查与团队开发习惯产生冲突时，如何平衡代码质量标准与实际开发灵活性？如何通过规则调整既避免过度约束又确保核心代码规范？读者或许会好奇：在云原生开发盛行的当下，如何将静态代码分析与动态测试策略结合形成更全面的质量保障体系？--Qwen3

C# Azure DevOps JetBrains Resharper Code Quality Pipelines

22

DEC

C# run tasks in a threads pool with fixed size

本文提出了一种基于C#的固定线程池任务调度方案通过线程安全队列实现动态任务分配解决了多核CPU资源利用与任务池扩展性之间的平衡问题。方案通过SafeQueue实现并发安全的任务队列管理CannonQueue服务则采用动态调度策略在保持最大并行度的同时支持任务池的动态扩展。当检测到线程空闲时自动触发任务分配机制确保核心资源的持续利用。针对依赖注入场景设计了QueueWithDependency方法通过服务作用域隔离解决了实体框架等依赖的生命周期问题。方案支持三种使用模式：即时启动的队列模式延迟启动的批量处理模式以及无等待的火并忘记模式。实现中通过Task.WhenAny实现非阻塞任务监控并通过日志记录实时展示任务运行状态。该方案引发的思考包括：如何在不同硬件配置下自适应调整并行度？当任务处理时间差异较大时如何优化资源分配？如何设计任务失败的重试机制？以及在高并发场景下如何平衡内存占用与吞吐量？--Qwen3

C# Async Task Multi-Threading async programming task queue

06

DEC

ASP.NET Core Integration Test using MSTest

本文探讨了在ASP.NET Core集成测试中替代官方推荐xunit框架的可能性问题。通过实践验证表明MSTest可以完美替代xunit实现完整测试流程文章展示了如何通过移除xunit依赖并安装MSTest组件构建基于MSTest的测试架构重点解析了测试服务器的启动机制与HTTP请求的自动化验证方案。测试类通过动态创建服务器实例并绑定指定端口实现了与真实环境的模拟交互同时通过[TestMethod]和[DataRow]特性构建了可扩展的测试用例体系。值得注意的是测试框架的切换并非简单的工具替换而是需要重构测试生命周期管理尤其在服务器启动与资源释放环节必须建立严格的[TestInitialize]和[TestCleanup]机制以确保测试环境的隔离性。这种测试架构的迁移启示我们软件测试的灵活性不仅体现在框架选择上更在于对测试流程的深度控制。当面对不同测试框架的适配问题时我们是否应该优先考虑开发习惯还是框架特性？在测试稳定性与框架扩展性之间是否存在最优解？这些问题或许能引发开发者对测试策略更深层的思考。--Qwen3

ASP.NET Core C# .NET Core Test MSTest Functional Test Integration Test

14

OCT

Fire and forget in ASP.NET Core with dependency alive

在ASP.NET Core中实现fire and forget模式时，开发者常通过Task.Run启动异步任务但可能忽略依赖项生命周期管理。当控制器触发耗时任务后自身即被释放，导致注入的依赖可能提前销毁从而中断任务执行。文章揭示了直接在控制器中调用Task.Run的潜在风险，提出通过单例服务CannonService解决依赖存活问题的创新方案。该服务利用IServiceScopeFactory动态创建作用域，确保任务执行期间依赖项始终有效。通过将耗时操作迁移至单例服务中执行，既避免阻塞主线程又能保持依赖存活，同时引入异常处理机制增强任务健壮性。这种设计模式突破了传统依赖注入的生命周期限制，为长时异步任务提供了优雅的解决方案。文章最后抛出值得深思的问题：当任务依赖多个作用域服务时，如何平衡资源占用与任务可靠性？当系统负载剧增时，这种基于Task.Run的调度策略是否存在潜在瓶颈？或许我们该重新审视fire and forget在现代云原生架构中的最佳实践。--Qwen3

ASP.NET Core C# Async Fire and forget dependency injection singleton service

13

OCT

How to serialize JSON object in C# without Newtonsoft Json

在C#开发中遇到JSON序列化需求却受限于Newtonsoft.Json的版本冲突问题时如何破局？本文提出了一种纯C#解决方案通过DataContractJsonSerializer实现自定义JSON转换器。开发者只需将MyJsonConverter类集成到项目中即可获得与Newtonsoft.Json相似的序列化能力该方法通过MemoryStream实现内存级数据流转无需依赖第三方库即可完成复杂对象的递归序列化。示例中的书籍关联结构验证了其处理嵌套对象的能力当对象的Related字段包含子对象时转换器能自动处理null值并保持结构完整性。这种轻量级方案不仅解决了依赖冲突问题还为资源受限场景提供了替代方案但同时也引发更多思考：当面对包含循环引用的对象时这种转换机制会如何表现？在性能对比中纯C#方案与Newtonsoft.Json的效率差异有多大？当需要处理包含动态类型的复杂数据结构时是否需要对转换器进行扩展？这些问题的答案或许能帮助开发者在不同场景下做出更明智的技术选型。--Qwen3

C# JSON .NET Newtonsoft.Json JSON handling Custom JSON solution

16

JUN

C# Rotate the square matrix

这篇文章探讨了C#中旋转方形矩阵的算法实现并提供了一个基于递归的解决方案通过分层处理矩阵的每条边将空间复杂度控制为O(1)的同时实现了原地旋转作者在代码中构建了递归终止条件与分层逻辑使得每一圈旋转操作都能精准定位到对应的四个元素位置这种设计巧妙地将二维数组的旋转拆解为多个可重复利用的单步操作并借助padding参数逐步向矩阵内层推进代码通过保存四个目标位置的数值并进行环状赋值完成了单个元素的旋转过程最后通过递归调用将问题规模缩小到更小的子矩阵文章引发的思考包括如何在非方形矩阵中实现旋转操作是否存在更优的时间复杂度方案或者能否将这种分层策略应用到其他二维数组变换中当矩阵的维度不是偶数时这种递归方式是否仍能保持最优解这些问题或许能为读者在处理数组变换问题时提供新的思路--Qwen3

C# Algorithm Matrix Math Matrix Rotation C# Implementation

12

JUN

Creating a proxy to another URL with ASP.NET Core

本文介绍了一种在ASP.NET Core中实现HTTP代理的轻量级方案通过扩展方法将HttpContext转换为可重用的HttpRequestMessage并构建完整的请求转发与响应处理链。文章重点展示了两个核心方法CreateProxyHttpRequest与CopyProxyHttpResponse的实现逻辑：前者通过解析原始请求方法处理流式数据并复制请求头信息构建目标请求对象后者则通过处理响应状态码头信息及响应体实现透明返回。这种设计允许开发者在现有项目中灵活实现请求代理功能而无需部署独立的代理服务器。值得注意的是实现过程中针对不同HTTP方法的处理差异以及头信息的精细拷贝策略都体现了对HTTP协议的深入理解。当访问特定路由时请求将被代理至目标URL（如示例中的google.com）并保持浏览器端的无感知交互。这种技术方案为API调试中间件开发等场景提供了新的可能性但同时也引发思考：如何在实际项目中平衡代理功能的灵活性与安全性？如何处理更复杂的路由规则与身份验证需求？当请求链延长时如何优化性能瓶颈？这些问题都值得开发者结合具体场景深入探索与实践。--Qwen3

ASP.NET Core C# Reverse Proxy Web Proxy HTTP Proxy

14

MAY

EF second layer cache to enhance your SQL database performance based on Redis

EF Core作为轻量级ORM框架在简化数据库交互的同时也面临高频查询带来的性能瓶颈当首页数据等静态内容被反复请求时数据库连接资源消耗与响应延迟成为亟待解决的问题传统手动缓存方案虽然能通过内存缓存降低查询频率却需要开发者自行处理缓存穿透缓存失效等复杂逻辑且在分布式场景下难以维护数据一致性EFCoreSecondLevelCacheInterceptor插件的出现改变了这一状况它通过拦截器机制自动追踪实体变更事件在实体插入更新或删除时自动刷新缓存开发者无需修改业务代码即可实现全查询自动缓存化但这种基于内存的方案在多实例部署时仍会遭遇缓存不一致问题当数据库通过存储过程或外部服务更新时本地缓存可能已失效此时引入Redis作为分布式缓存存储成为关键方案通过EasyCaching.Redis集成EF二级缓存将缓存数据集中存储在Redis集群中无论应用实例如何扩展都能保证缓存数据的实时同步与一致性配置过程仅需简单修改Startup类添加Redis连接信息即可实现从内存缓存到分布式缓存的无缝迁移当你的应用已通过Redis实现缓存分布式化是否考虑过如何设计缓存预热策略？当Redis集群出现网络分区时如何保证缓存可用性？这些未解难题或许正是你优化系统架构的下一个突破口--Qwen3

ASP.NET Core C# SQL Server SQL Entity Framework Core Azure Redis Caching Cache

07

MAY

Get unique random numbers in C#

本文提出了一种基于RSA算法的非重复随机数生成方案，解决了传统方法在性能与内存占用上的瓶颈。传统线性同余法通过逐个生成并比对数据库实现去重，其O(n²)的时间复杂度在数据量增大时导致性能急剧下降；而序列打乱法虽可实现O(n)时间复杂度但需要O(n)的内存空间。作者创新性地将密码学中的模幂运算与素数特性结合，通过构造一一映射函数C = A^D mod N实现O(n)时间复杂度和O(1)空间复杂度的随机数生成。该方法巧妙利用素数分解特性，当N为两个不同素数乘积时，通过计算D和E的模反元素建立双向映射关系，确保生成的随机数既无重复又无遗漏。代码实现中通过素数检测、参数验证和自然数遍历等模块构建完整解决方案，最终测试结果验证了随机数的唯一性和分布的均匀性。该方法在处理百万级数据时展现出显著优势，但其有效性依赖于N的可分解性，这引发了对算法适用范围与安全性的思考：当N无法分解为两个素数时是否仍有替代方案？如何在资源受限场景中平衡性能与安全性？或许我们还能思考，密码学技术在算法优化中还有哪些未被开发的潜力？--Qwen3

C# .NET Core Algorithm Random Numbers Unique random Non-repeat Random

Anduin's Tech Blog

C#