.NET

04

JUN

How to use C# to manage InfluxDB data

这篇文章介绍了如何通过C#语言操作InfluxDB时间序列数据库的完整实践路径。InfluxDB作为专为高并发时序数据设计的存储引擎正在重塑物联网传感器数据、应用性能监控等场景的数据处理方式。通过Docker容器化部署可快速完成环境搭建并获取API访问权限。C#开发者借助InfluxDB.Client库能够实现数据写入、查询的全流程操作——从配置连接参数到创建存储桶，从构建带时间戳的PointData对象到使用InfluxDBQueryable或Flux查询语言进行数据检索。代码示例展示了如何将日志信息结构化存储，并通过两种不同查询方式验证数据持久化效果。这种将C#与时序数据库结合的架构不仅简化了实时数据分析的复杂度，更引发了关于传统数据处理范式与时间维度深度结合的思考：当所有数据都天然携带时间戳时，我们是否需要重新定义数据建模的规则？在物联网设备持续产生指数级时序数据的今天，如何通过C#语言特性优化数据流处理效率？这些值得探索的问题或许能启发开发者重新审视实时数据的价值挖掘路径。--Qwen3

C# Database .NET Docker InfluxDB Flux Query Language

27

NOV

C# start a process and get output. (Fix process won't quit issue)

在C#中启动外部进程并获取输出看似简单但隐藏着易被忽视的陷阱。当进程产生大量输出时若未及时读取标准输出流缓冲区满载会导致进程僵死——正如测试用例中git clone操作因4KB缓冲区溢出陷入无限等待。这种现象揭示了进程间通信的本质矛盾：输出流消费速度必须匹配生产速度。文章通过对比错误代码与修正方案展示了如何通过并行读取输出流与等待退出状态打破僵局。修正后的实现采用MemoryStream捕获输出流并借助Task.WhenAll同步三路异步操作（标准输出/标准错误/进程退出），这一设计既避免了阻塞又保留了完整输出内容。测试套件验证了方案的鲁棒性：从超时处理到异常捕获再到大规模输出验证，每个用例都暗含进程管理的关键考量。值得注意的是，这种解决方案引发更深层的思考：当缓冲区大小成为系统瓶颈时如何在不同编程语言中实现类似机制？若目标进程同时写入标准输出和标准错误流能否设计更高效的消费策略？最后提出一个开放性问题：当外部进程的输出模式不可预测时，我们该如何动态调整流读取策略以确保系统的稳定性与响应性？--Qwen3

C# git .NET Process Process Management Git Commands

11

OCT

挑选合适尺寸的显示器

这篇文章探讨了显示器选购中分辨率与尺寸的匹配逻辑，揭示了像素密度（PPI）与操作系统缩放机制之间的复杂关系。作者指出显示器并非越大越好，而是需要通过精确计算PPI值来匹配操作系统的默认渲染标准——Windows与Linux默认96PPI，MacOS则沿用72PPI的历史遗留标准。当显示器PPI接近目标值的整数倍时，整数倍缩放能实现最清晰的显示效果，而非整数倍缩放（Fractional Scaling）则必然导致锯齿化。文章通过C#代码展示了PPI计算公式，并以LG OLED 42C2、Surface Studio 2+、Apple Studio Display等典型案例，揭示了不同设备在缩放策略上的差异。令人意外的是，某宝2000元的4K显示器因163PPI的尴尬数值，被迫采用175%的非整数倍缩放反而更模糊。开发者需要特别注意在96PPI环境下进行UI测试，而普通用户则需重新审视显示器的尺寸与分辨率是否符合操作系统设计逻辑。文章最后抛出一个值得深思的问题：当你的显示器PPI恰好是96的1.5倍时，是该妥协选择150%缩放接受模糊，还是接受100%缩放导致文字过小？这背后折射出的不仅是技术选择，更是人机交互设计哲学的深层矛盾。--Qwen3

C# .NET Display Monitor Resolution Display Resolution

19

JUL

Use your own cert to sign your package to identify your code identity.

本文探讨了数字证书在代码身份识别中的应用及其技术实现路径。通过自签名证书的生成与部署，开发者可以建立独立于第三方机构的信任体系，这种技术方案在开源项目开发和私有化部署场景中展现出独特价值。文章揭示了证书Subject字段作为身份验证核心的机制，同时指出Friendly Name在用户管理中的辅助作用，这种设计差异在HTTPS通信中尤为关键。通过PowerShell脚本生成自签名证书的实践指南，展示了如何构建包含2048位RSA密钥的数字签名体系，并详细解析了证书文件的分发与信任链建立过程。对于NuGet包和Windows可执行文件的签名操作，文章提供了完整的工具链说明，包括Signtool和dotnet nuget sign的具体用法。值得注意的是，在中国获取商业证书的特殊挑战揭示了数字身份认证体系的地域性差异，这种技术与政策的交织关系值得深入思考。当开发者面对证书信任提示时是否意识到，这背后涉及的不仅是技术验证，更是数字世界中身份认证的哲学命题？如何在自签名与商业证书之间找到平衡点，或许正是每个开发者必须面对的技术伦理选择。--Qwen3

C# Certificate .NET Windows Sign Digicert Code Sign Signature nuget

09

MAY

Show .NET code coverage rate and unit test status with GitLab CI\CD pipeline

本文展示了一种通过GitLab CI/CD管道自动展示.NET项目代码覆盖率与单元测试状态的完整实践方案。文章从项目结构配置开始指导读者如何通过NuGet包集成coverlet.collector和JunitXml.TestLogger实现测试数据收集，并通过精心设计的.gitlab-ci.yml文件构建包含构建测试发布三个阶段的自动化流水线。核心创新点在于利用正则表达式提取覆盖率数据并结合reportgenerator工具生成标准化报告，最终在GitLab界面实现测试结果可视化和代码覆盖率徽章展示。这种方案不仅实现了持续集成的自动化验证功能，更通过可视化数据为代码质量监控提供了直观依据。当测试覆盖率在合并请求中动态呈现时开发者能即时感知代码改动对测试覆盖的影响这种实时反馈机制是否能推动团队建立更严谨的测试文化？当覆盖率数据与代码质量指标产生关联时如何设计合理的阈值预警机制？或许我们更应该思考在追求高覆盖率的同时如何确保测试用例的有效性和维护性？这些值得深思的问题正在等待每一位实践者去探索答案。--Qwen3

.NET Test Code coverage Continuous Integration GitLab junit YAML

17

DEC

Validate an object in any C# projects

这篇文章探讨了C#项目中对象验证的最佳实践并提出了重构传统验证逻辑的创新思路。通过对比传统多层if-else验证方式带来的代码冗余问题，揭示了将验证规则内聚到数据模型中的重要性。文章展示了如何在非ASP.NET Core项目中复用框架的模型验证机制，通过定义[Required]、[MinLength]等数据注解实现声明式验证，并进一步演示了自定义[NoSpace]属性验证规则的完整实现过程。特别值得关注的是文中提供的递归验证解决方案，该方案利用反射技术实现了对嵌套对象图的自动验证，为复杂对象的校验提供了优雅的解决方案。当面对跨层级对象的验证需求时如何设计更智能的规则继承机制？当验证规则需要动态调整时如何构建可扩展的验证框架？这些开放式问题为开发者提供了深入思考的方向，启发我们探索如何将验证逻辑与领域模型深度结合，同时思考如何将这种声明式验证模式迁移到其他编程范式中。--Qwen3

ASP.NET Core C# .NET Validation DataAnnotations Custom Validation

03

DEC

C# Play with GZip.

这篇博客展示了如何通过C#为字符串添加GZip压缩功能的扩展方法揭示了数据压缩技术在现代编程中的实用价值。通过构建包含ZipToBase64和UnZipBase64方法的扩展类开发者可以轻松实现字符串的压缩与解压操作在示例代码中反复压缩的字符串通过Base64编码实现了体积的显著缩减这种数据处理方式是否暗示着更高效的存储方案值得深入思考当压缩后的数据长度突破原始字符串限制时是否会引发新的技术挑战而Base64编码与GZip压缩的组合是否意味着存在更优的编码策略当我们面对海量数据时这种压缩方法是否能承受性能压力又该如何平衡压缩率与处理效率的矛盾这些问题或许能为优化数据传输方案提供新的思路而测试用例中验证的压缩效果是否意味着在特定场景下可以完全替代传统存储方式呢--Qwen3

C# .NET Compress GZip Base64 string extension

29

SEP

Why you should never use `Console.WriteLine`

本文探讨了在库代码中使用`Console.WriteLine`的潜在问题及其替代方案。文章指出`Console`类与标准输出的强耦合特性会导致库代码与业务逻辑的依赖混乱——当库被单元测试框架或Web服务器调用时，控制台输出可能完全失效违背依赖倒置原则。通过引入`ILogger`接口抽象层可实现日志系统的解耦，使日志记录与具体输出方式分离。实际应用中可通过`Microsoft.Extensions.Logging`框架构建可扩展的日志体系：通过依赖注入注册日志服务后，开发者可动态切换控制台日志、文件日志或Application Insights等不同输出方式，同时支持日志分级和格式化功能。文章通过代码示例演示了如何通过服务集合配置日志系统，并指出即使不使用依赖注入框架也能通过`LoggerFactory`快速创建控制台日志实例。值得注意的是在终端UI应用或自定义日志实现器等特定场景下，`Console`类仍可作为直接交互工具。那么当你的应用需要同时处理多租户日志时，如何设计日志上下文关联机制？当服务器集群规模扩大时，控制台日志是否仍然能胜任分布式追踪需求？这需要开发者重新思考日志系统的架构设计边界。--Qwen3

C# .NET Core Console App .NET Logging ILogger

25

SEP

Retry with exponetial back-off on C#

本文介绍了一个基于C#实现的指数退避重试引擎设计与实现其核心通过动态计算等待时间在多次失败后自动触发重试机制代码中通过递增的幂次方随机数生成回退间隔时间并结合超时控制与异常过滤策略为开发者提供了灵活的重试解决方案该引擎允许通过when参数自定义重试条件并支持异步任务执行与超时熔断机制在实际应用中开发者可以将其封装到网络请求或分布式任务中以应对临时性故障但如何平衡重试次数与系统负载？当重试策略与业务场景的关联性增强时是否需要引入更智能的决策模型？当异常类型复杂化时如何设计更精准的过滤规则？这些问题都值得在构建可靠系统时深入思考--Qwen3

C# .NET Retry Retry Engine Exponential Backoff Exception Handling

04

AUG

Query Kusto database with C# and get result as List<T>.

该实现通过双缓冲机制和任务调度优化Kusto数据写入性能采用双缓冲策略交替使用_activeBuffer和_secondaryBuffer减少内存占用和数据碎片冷却引擎动态计算写入延迟时间平衡写入频率与数据量大小通过ReaderWriterLockSlim和锁机制实现线程安全的数据入队与缓冲区交换操作引擎任务负责批量写入数据并在缓冲区数据量不足时自动休眠冷却引擎负责在休眠后重新唤醒写入任务形成热状态下的持续写入能力支持高并发场景下的非阻塞数据添加通过CalculateSleepTime方法根据缓冲区数据量动态调整休眠时间避免频繁写入和资源浪费SyncAsync方法确保所有待处理数据最终持久化实现可靠的数据同步机制。--Qwen3

C# .NET Core Azure .NET Kusto Azure Data Explorer KQL

29

JUL

Build a common cache service for your C# app.

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

ASP.NET Core C# .NET Core Performance Caching .NET Cache MemoryCache

09

DEC

Display code coverage information for .NET Core project using Azure DevOps.

本文深入解析了如何在Azure DevOps中为.NET Core项目展示代码覆盖率数据，通过构建管道配置和测试结果分析，揭示了软件质量保障的关键路径。文章不仅提供了从构建管道创建到覆盖率徽章生成的完整操作链，更引发了对测试覆盖度与代码质量关系的深层思考——当测试覆盖率显示为87%时我们是否应该满足？如何通过覆盖率数据识别潜在的测试盲区？在跨平台开发场景中Linux系统仍不支持代码覆盖率收集这一现状是否会影响开发策略？文章通过Windows平台专有的构建配置要求，提示开发者在选择CI/CD环境时需权衡工具链兼容性与测试完整性。当覆盖率徽章以动态形式展示在readme文件中时这种可视化手段如何影响团队对代码质量的感知？更重要的是当测试通过率与覆盖率指标出现偏差时我们该如何解读这两组数据背后的技术含义？最终文章抛出一个值得所有开发者思考的问题：在追求100%覆盖率的过程中我们是否忽略了测试用例设计本身的质量？这种对测试方法论的反思或许比单纯追求数字更为重要。--Qwen3

.NET Core Azure DevOps .NET Test MSTest Integration Test Code coverage GitHub

Anduin's Tech Blog