lindexi
林德熙 - 微软最具价值专家和 .NET 基金会成员
林德熙
林德熙 - 微软最具价值专家和 .NET 基金会成员
本文记录我写的博客和我收集的博客
虽然说是手算，但是我还是会写一点 C# 代码，避免敲坏了计算器。我和大家保证，整个手算过程中，最终的计算结果只需要用到初高中知识。推导过程会用到部分高数的知识。我尽量将用到的知识点全列举出来，本文对学渣友好，期望能够拿出纸笔和 VisualStudio 的伙伴阅读完本文能够真的理解神经网络 BP 传播算法是如何计算的
Windows 调试工具课程——在软件万种死法中调试出原因
本文记录我读 WPF 源代码的笔记，本文将介绍在 WPF 底层是如何从 Win32 的消息循环里获取到的 WM_POINTER 消息处理转换作为 Touch 事件的参数
本文将带领大家入门 dotnet 的 SourceGenerator 源代码生成器技术，期待大家阅读完本文能够看懂理解和编写源代码生成器和分析器
本文将告诉大家如何在 WPF 里面，接收裸 Win 32 的 WM_Pointer 消息，从消息里面获取触摸点信息，使用触摸点信息绘制简单的笔迹
现在软件代码签名已经不能用 pfx 软证书了，需要搭配 FIPS140-2 Level2、Common Criteria EAL4级以上或者同等认证级别的硬件，如 USB 令牌、硬件安全模块 HSM 等才能完成签名
本文记录一个开机自动启动实现方法，通过写入到注册表实现开机之后，用户登录完成之后让应用程序开机自启
众所周知，在 C# 里面是没有只读局部变量的功能的。但有趣的 C# 语法让咱可以使用现有的 using 关键字间接实现只读局部变量
本文告诉大家如何使用本文提供的输入法快速输入带音调的字符
本文实质为翻译 .NET Core foundational libraries 官方文档的编码风格。
本文告诉大家如何在 WPF 开发一个可以自动启动的程序
在我的一次应用性能分析中，我发现了尝试获取 GlyphTypeface 的 CharacterToGlyphMap 属性的数量时，存在很大的耗时。经过阅读 WPF 源代码，我了解到了其中的原因，本文将和大家从底层源代码分析原因和给出解决方法
本文整理 dotnet 打包 CBB 组件为 NuGet 包时可以使用的配置的各个属性
我在寻找将一些拍摄出来的比较暗的图片进行光亮增强的算法，用于处理我出门拍的一些照片。我从博客园找到了 Imageshop 大佬记录的伊拉克团队的TAGC（低光增强效果）算法实现，通过阅读大佬的博客和对应的论文，基于 WPF 的 WriteableBitmap 实现 TAGC 低光增强效果算法
在 Intel 11 代锐炬 Intel® Iris® Xe Graphics 核显设备上，如果此设备使用旧版本驱动，则可能导致 WPF 的 WriteableBitmap 停止渲染。此问题和 WPF 无关，此问题是 Intel 的 bug 且最新驱动版本已修复
本文整理我写的和我收集的触摸博客
在 WPF 里面，可以通过 StylusPlugIn 直接从触摸线程获取触摸消息，不需要经过 UI 线程。如此可以实现更低的触摸延迟。但是 StylusPlugIn 的 OnStylusDown\Move\Up 方法都可能是从触摸线程或 UI 线程调入，需要警惕这里的多线程安全问题
异常的堆栈信息，通常都是在抛出的时候自动记录当前的异常堆栈信息。在某些特殊情况下，期望修改异常堆栈，此时需要用到 dotnet 内置的 ExceptionDispatchInfo 机制
本文记录 WPF 触摸的一个已知问题，仅在开启 WM_Pointer 消息之后，将应用程序运行在包含多个屏幕的带触摸屏的设备上，如此时在非主屏幕的触摸屏上进行触摸，使用 GetStylusPoint 或 GetIntermediateTouchPoints 方法获取触摸点时，将会发现所获取的触摸点的坐标是偏的，偏的坐标差值刚好是整个屏幕距离
本文收藏我给 WPF 做的性能测试。在你开始认为 WPF 的性能存在问题的时候，不妨来这篇博客里找找看我做过的测试。我记录的测试都是比较纯净的测试项目，没有业务逻辑的干扰，写法也正常，可以更加真实反映 WPF 的性能，减少因为奇怪的业务逻辑以及逗比的写法的影响
本文告诉大家如何在通过更改注册表的设置，从而更改平板电脑设置 Tablet PC Settings 的左右手使用习惯 Handedness 的惯用左手和惯用右手选项
被微软收购的 GitHub 越来越好用，拥有大量免费的工具资源和构建服务器资源，再加上私有项目的无限制使用，我有大量的项目都在向 GitHub 迁移。通过 GitHub 的 Action 的自动构建，可以用上微软土豪的服务器资源，进行自动化测试和构建。对于 CBB 来说，发布就是打出 NuGet 包然后上传到内部 NuGet 服务器。此时遇到的问题是，如何在 GitHub 上执行打包，打包的时候如何指定 NuGet 包的版本号。因为 CBB 的特殊性，我要求每个 NuGet 正式发布的包都应该有一个对应的 Tag 号，这样将 NuGet 库安装到项目里面，之后发现问题了还能找到对应版本的代码
我现在的团队内部用的是 Gitlab 工具，在此工具上提供了 Gitlab CI CD 用于做自动化测试和构建。对于 CBB 来说，发布就是打出 NuGet 包然后上传到内部 NuGet 服务器。此时遇到的问题是，如何在 Gitlab 上执行打包，打包的时候如何指定 NuGet 包的版本号。因为 CBB 的特殊性，我要求每个 NuGet 正式发布的包都应该有一个对应的 Tag 号，这样将 NuGet 库安装到项目里面，之后发现问题了还能找到对应版本的代码 本文告诉大家如何配合 Gitlab 做自动推 Tag 时打包 NuGet 包。也就是本地打一个 Tag 号，推送到 Gitlab 上，就会出发 Gitlab 的自动构建，自动构建里面将会获取 Tag 版本号，然后打出 NuGet 包推送到服务器
无论是麒麟还是 UOS 系统，所采用的 GLibC 版本都比较低。默认在 GitHub Action 上构建用的是 ubuntu-latest 较新的版本。进行 AOT 发布的 dotnet 程序将因为 GLibC 版本太新，而无法在麒麟或 UOS 等国产化系统上跑起来
我的需求是需要有一个能够构建出 dotnet 的 AOT 包的环境，要求这个环境能解决 glibc 兼容依赖的问题，能打出来 x64 和 arm64 的 AOT 的包，且能够运行 gitlab runner 对接自动构建
在 2020.11.10 官方正式发布了 .NET 5 正式版。而我花了一周的时间进行踩坑和预研，本文将告诉大家如何在自动化服务器上搭建 dotnet 5 的构建和运行环境
我不能用官方的镜像，因为我需要在小伙伴构建的 debian 镜像上面安装 dotnet sdk 用来做构建，其实在 docker 里面需要找到一个个文件，然后复制代码
从设计架构上，无论是 WPF 还是 ASP.NET Core 框架，都是在 dotnet 运行时上层的应用，两个框架处于平级的结构。理论上讲，两个平级的框架只要不存在特殊的情况，都是能够相容存在的。本文将和大家介绍一个非常简单的方法，在一个进程内同时跑起 WPF 和 ASP.NET Core 框架
之前我写过博客让 WPF 和 ASP.NET Core 跑在一个应用程序进程里面，这样的方式十分简单方便，缺点是输出路径会带一些 ASP.NET Core 的 DLL 文件。本文将来尝试对 ASP.NET Core 进行 AOT 发布为类库，通过类库调用方式在 WPF 里引用 ASP.NET Core 开启 HTTP 服务
这是我今天在散步过程的胡思乱想内容
对 Avalonia 进行 AOT 发布时，会发现存在几个库文件无法被打进入到 exe 可执行文件里面，于是进行分发的时候又需要进行压缩。现在很多用户已经不懂如何解压缩了，我就在想着如何只发布单个文件
本文将和大家演示如何在 WPF 里面，使用 WNetUseConnection 连接 SMB 网络资源
故事的背景我在一个双屏设备上，我想要获取每个显示器屏幕对应的 EDID 信息。我在一台麒麟系统的设备上，通过 RandR 的方式获取 EDID 信息，进而读取屏幕物理设备信息
在 X11 里面，可以指定一个窗口应该在哪个屏幕上全屏显示，甚至可以指定窗口横跨几个屏幕显示