lindexi
林德熙 - Windows 10 App Developer
林德熙
林德熙 - Windows 10 App Developer
在 WPF 里面，带了基础的文本库功能，如 TextBlock 等。文本库排版的重点是在文本的分行逻辑，也就是换行逻辑，如何计算当前的文本字符串到达哪个字符就需要换到下一行的逻辑就是文本布局的重点模块。本文来简单聊聊 WPF 的文本布局逻辑
本文告诉大家如何修复 VisualStudio 构建时没有将 NuGet 的 PDB 符号文件拷贝到输出文件夹的问题。如果 VisualStudio 构建时没有将 NuGet 的 PDB 符号文件拷贝到输出文件夹，那将会在调试的时候，由于找不到 PDB 符号文件而加载符号失败
本文将告诉大家如何在 dotnet 的控制台模式下，采用 MAUI 自绘库 Microsoft.Maui.Graphics 进行绘图，设置 Microsoft.Maui.Graphics 底层调用 Microsoft.Maui.Graphics.Skia 库的 Skia 进行具体的绘图实现，此控制台可以跨平台运行，我在本机 Win10 和 WSL 的 Ubuntu 上都运行过，输出的结果图片像素级相似。本文将告诉大家如何采用 Microsoft.Maui.Graphics 进行跨平台的自绘
谷歌的 Skia 的一个卖点就是提供了完美的 SVG 的支持，包括输入和输出。输入指的是给一张 SVG 图片，将这个 SVG 渲染出来。输出就是将输出画面保存为 SVG 格式的图片。自然 SkiaSharp 是 Skia 的封装，也就带上了此功能。本文将告诉大家如何在 SkiaSharp 里面设置画面输出为 SVG 图片，使用 SkiaSharp 制作和编辑 SVG 图片
这是一个当前还没开发完成的功能，准确来说连预览版也算不上的功能。我原本以为 MAUI 是无法在 WPF 上面跑的，然而在看完了 MAUI 整个大的设计，才了解到，原来 MAUI 是一个非常庞大的开发项目。在 MAUI 里面，虽然现在是正式发布的，但正式发布的版本里面只有采用原生控件进行绘制的方案。这和官方开始的宣传不符合，在阅读了 MAUI 相关文档才发现，实际上 MAUI 还有一个很大的部分，那就是自绘部分，还没完成，代码也分了仓库，这就是一开始没找到的原因。本文将告诉大家 MAUI 还没发布的这部分大杀器
在2022的5月份，某软正式发布了 MAUI 跨平台 UI 框架。我本来想着趁六一儿童节放假来写几篇关于 MAUI 入门的博客，可惜发现我不擅长写很入门的博客。再加上 MAUI 似乎是为了赶发布日期而发布，只能勉强说能开发了，能用了。于是我就来开始假定大家是一个成熟的 MAUI 开发者了，开始进入复杂控件自绘的自定义绘图渲染的博客
本文记录 WPF 应用程序，因为系统的颜色配置 Mscms.dll 组件损坏导致应用加载图片失败，从而启动失败的原因和解决方法
最近小伙伴告诉我，他的代码在打断点的时候，运行到断点，之后就可以运行。如果没有断点，他的代码就无法运行，经过了一段时间的研究才发现，原来打断点和不打断点是有一些区别。 本文来告诉大家，如果在自己的软件发现打断点之后程序和不打有区别，如在打断点之后程序可以运行，不打就不能运行，那么可以从下面的方法开始查看是否程序的问题。
默认的 WPF 为了保持行为兼容，没有开启弱事件的内存优化。可以在 WPF 中指定 Switch.MS.Internal.EnableWeakEventMemoryImprovements 和 Switch.MS.Internal.EnableCleanupSchedulingImprovements 开关来让 WPF 运行在 .NET Framework 4.8 或 .NET Core 3.0 以上版本时，自动开启弱事件内存优化。通过这个开关，将会更改部分行为，但是基本上不会有影响，因为影响的都是内存啥时候回收。这些开关和 WPF 应用所使用的开发版本无关，只和 WPF 应用所运行在的设备环境有关，如果在运行的设备上安装了 .NET Framework 4.8 版本，那么自动将会应用上，否则这个开关就和没有写一样
在 WPF 下，可以使用和 UWP 一样的 Pointer 触摸架构，只是开启的方式和 .NET Framework 版本有细微的差异
从设计上，用户控件 UserControl 就不是一个合适用来多次继承的类型，更不要说进行跨程序集继承自定义的 UserControl 用户控件。对于大部分的用户控件来说，都是采用组合现有的控件来实现的功能，本身应该被当成一个模块来进行使用。在 WPF 框架里面，从框架层阻止了开发者对自定义的 UserControl 用户控件跨程序集继承的逻辑，一旦尝试进行跨程序集继承，将在运行时抛出异常。本文将从源代码的角度告诉大家 WPF 框架是如何阻止跨程序集继承
在 .NET Framework 时代里面，有一组有趣的概念，那就是 SDK 和 Runtime 这两个概念。开发模式十分有趣，在开发者设备上，可以指定 .NET Framework 的 SDK 版本，例如指定 .NET Framework 4.5 版本。开发完成之后，分发给到用户，用户的电脑上所安装的 .NET Framework 基本都是 Runtime 版本。应用程序要求运行的 Runtime 版本一定要大于等于 SDK 的指定版本号 这就有一个非常有趣的问题了，我开发环境使用的 SDK 是低版本，例如 .NET Framework 4.5 版本。但用户的电脑上所安装的 .NET Framework 的 Runtime 版本是高版本，例如是 .NET Framework 4.7 版本，中间距离过了几年的版本。那行为如何保证相同？如果行为不能保证相同，那将会出现行为差异，在我的开发设备上跑得好好的，在一些用户电脑上，将会因为运行时基础库的版本差异从而变更行为，应用程序就不能符合预期跑起来了。事实上，咱没有碰到过这个问题，这是因为在 .NET Framework 层做了很多兼容处理逻辑，其中就包括本文要和大家聊的 WPF 框架的兼容行为
我有用户给我报告一个内存不足的问题，经过了调查，找到了依然是使用已经被标记过时的 HttpWebRequest 进行文件推送，推送过程中，由于 System.Net.RequestStream 将会完全将推送的文件全部读取到内存，导致了在 x86 应用下，推送超过 500MB 的文件，基本上都会抛出 OutOfMemoryException 异常
我对几个应用进行严格的启动性能评估，对比了在 .NET Framework 和 dotnet 6 下的应用启动性能，非常符合预期的可以看到，在用户的设备上，经过了 NGen 之后的 .NET Framework 可以提供非常优越的启动性能，再加上 .NET Framework 本身就是属于系统组件的部分，很少存在冷启动的时候，大部分的 DLL 都在系统里预热。启动性能方面，依然是 .NET Framework 比 dotnet 6 快非常多。而在破坏了 .NET Framework 的运行时框架层的 NGen 之后，可以发现 .NET Framework 的启动性能就比不过 dotnet 6 的启动性能。为了在 dotnet 6 下追平和 .NET Framework 的启动性能差异，引入与 NGen 的同等级的 ReadyToRun 用来提升整体的性能。本文将告诉大家如何在 dotnet 6 的应用里面，使用 Crossgen2 工具，给 DLL 生成 AOT 数据，提升应用启动性能
应用程序如果启动即闪退，那大部分时候日志模块还没初始化完成，很难通过应用自身的启动流程了解到应用启动失败的原因。本文来告诉几个不同的方法用来调查应用启动失败的原因
本文告诉大家如何在 MSBuild 里使用 Copy 复制文件
本文将来和大家推荐一个基于最友好 MIT 协议的完全在 GitHub 上开源的，可代替 .NET Remoting 的 IPC 本机多进程通讯库
本文：我遇到的WPF的坑
颜色变换是对基础颜色的相关属性的修改。 例如，透明度是与颜色相关的属性。 颜色转换被指定为任何颜色模型标签的子标签，可以在任何颜色加上颜色变换
通过 ReadyToRun 可以在程序集同时包含 IL 和本机代码，可以有效提升软件的启动速度
大家都知道，在 WPF 里面，可以让资源字典合并其他资源字典，从而定义出资源字典引用树。然而在资源字典引用树里面，如果没有理清关系，将可以作出一个超级复杂的引用关系网。如果在性能优化中，将网断开部分，可能就会出现找不到资源的情况。本文将告诉大家 WPF 的资源字典树在引用和寻找关系上的坑
我尝试在 dotnet 6 使用 File.Exists 判断管道是否存在，如果管道存在再进行连接。然而这个逻辑将会接下来的 NamedPipeClientStream 调用 Connect 连接失败
本文告诉大家如何在 WPF 里面使用 luna 等复古主题
在应用启动过程里，除了主 UI 线程之外，如果还多启动了新的 UI 线程，且此新的 UI 线程碰到 ContentPresenter 类型，那么将可能存在让新的 UI 线程和主 UI 线程互等。这是多线程安全问题，不是很好复现，即使采用 demo 的代码，也需要几千次运行才能在某些配置比较差的机器上遇到新的 UI 线程和主 UI 线程互等，应用启动失败。本文来告诉大家复现的步骤，以及原因，和解决方法
在 dotnet 的最佳实践里面，不推荐在静态构造函数里面包含复杂的逻辑，其中也就包含了本文聊的和多线程相关的锁的使用。最佳做法是尽量不要在静态构造函数里面碰到任何和锁以及多线程安全相关的逻辑。本文来告诉大家，在静态构造函数里面使用锁将带来的问题以及原因
我使用 User32 的 SetWindowPos 方法去设置一个跨进程的窗口，这个窗口是停止响应的，将让调用的 SetWindowPos 方法卡住，不继续执行逻辑。通过堆栈分析是卡在 NtUserSetWindowPos 方法上，调用 SetWindowPos 方法不返回
官方的 dnSpy 在 2021 时，由于某些吃瓜的原因 wtfsck 将 dnSpy 给 Archived 掉，在大佬被哄好之前，预计是不再更新。最新官方版本对 dotnet 6 的支持较弱，对于很多 dotnet 6 应用都无法成功调试，附加调试上去将会让应用卡住。好在 dnSpy 是开源的，也刚好 lsj 大佬改得动，于是改了一个支持 dotnet 6 的版本
在经过了两年的准备，以及迁移了几个应用项目积累了让我有信心的经验之后，我最近在开始将团队里面最大的一个项目，从 .NET Framework 4.5 迁移到 .NET 6 上。这是一个从 2016 时开始开发，最多有 50 多位开发者参与，代码的 MR 数量过万，而且整个团队没有一个人能说清楚项目里面的所有功能。此项目引用了团队内部的大量的基础库，有很多基础库长年不活跃。此应用项目当前也有近千万的用户量，迁移的过程也需要准备很多补救方法。如此复杂的一个项目，自然需要用到很多黑科技才能完成到 .NET 6 的落地。本文将告诉大家这个过程里，我踩到的坑，以及学到的知识，和为什么会如此做
在 dotnet 里面，使用 await 进行异步逻辑，默认是会尝试切换回调用 await 的线程同步上下文。这个机制对于大多数的上层应用来说都是符合逻辑且方便的逻辑，例如对于带 UI 线程的 WPF 或 WinForms 等应用，基础开发的执行逻辑基本都是在 UI 线程上，此时进入一次 await 再出来，期望如果是进入 await 之前是在 UI 线程，那么执行 await 完成之后，退出的代码也能在 UI 线程执行，正好这就是 dotnet 的默认行为。但是对于库开发者来说，情况就反过来的，库的开发者大部分时候更期望默认不要切换回调用方的线程，采用 Fody 的 ConfigureAwait.Fody 库，可以控制此默认的行为。本文将告诉大家如何使用 ConfigureAwait.Fody 库
本文记录我将应用迁移到 dotnet 6 之后，在 Win7 系统上，因为使用 HttpWebRequest 访问一个本地服务，此本地服务开启 https 且证书链在此 Win7 系统上错误，导致应用内存泄露问题。本文记录此问题的原因以及调查过程
本文来告诉大家，在 OpenXML 里面的 Geometry 的如 gdLst 和 ahLst 和 pathLst 等里面参数的公式的参数含义
官方团队为了防逗比，默认将 OutputType 输出类型重定向为 WinExe 类型，这样能解决很多新手遇到的 WPF 项目显示出黑框控制台界面问题。而对于一些老司机来说，这个特点反而有点迷，特别是在尝试打开控制台调试的时候
我的应用是独立发布的，在用户的设备上不需要额外去安装 .NET 运行时。但是我的应用有一个需求是下载另一个应用作为插件，由本应用调起插件进程。本文告诉大家如何解决调用插件的进程时，赋值给插件进程运行时的文件夹路径，解决环境依赖
在安装完成了 100000000 个软件之后，我 1T 的 C 盘的空间终于不足了，由于安装了大量的特别挑的不专业的软件，强行放在其他的盘将水土不服。于是在老师傅的指导下，我采用了 mklink 神奇命令行，通过 mklink 可以实现将实际的文件放在其他的盘，然后建立链接到原先的地方，在应用上层基本感知不到文件的实际存储地方已经被更换。也就是物理上的文件存放是可以在另一个磁盘上，但软件以为文件还在原来的地方 这是一个不错的方法，我需要处理的文件夹还稍微有点多，就想着写一点小工具，在 Total Commander 里面，辅助我快速完成工作
本文记录一些代码审查套路，在看到小伙伴写出某些代码的时候可以告诉他这样写有锅