我以前将一个目录作为 OneDrive 同步目录使用，所有文件都保留在本地，后来停用了这个同步目录。
这些文件可以正常读取，图片、视频却只能显示默认图标，资源管理器无法生成缩略图。奇怪的是，将文件剪切到原 OneDrive 目录外，再剪切回来，缩略图就恢复了。
这并不是缩略图缓存或视频解码器的问题，而是 OneDrive 的按需文件（Files On-Demand）在 NTFS 中留下了云文件元数据（cloud file metadata）。这套机制由 Windows 的 Cloud Filter API 提供[1]。
重要
已过时，仅Visual Studio 2022需要此操作，新版Visual Studio 2026内置的PowerShell已经自带命令补全（PSReadLine）
如果你下载了Windows Terminal和最新版的PowerShell Core就会发现，
如果不特殊设置的话，即使我们使用的Windows Terminal拥有命令补全，Visual Studio 2022的终端仍然没有任何补全。
从事C#框架开发的几乎都是首选Visual Studio的。
WinUI 3作为一个新生框架，Rider对它的支持并不好，目前为止仍然无法编译通过。
Visual Studio Code也是一个选择。
但它作为一个几乎需要从零搭建环境的“IDE”，使用它不是明智的选择。
编写大型项目的时候，经常需要引入插件系统以便对功能进行扩展，同时降低功能间的耦合性。
但一般的插件系统大量运用反射技术，并且需要动态加载、卸载插件，听起来和AOT格格不入。
确实，在AOT运行环境下，没有.NET运行时，这限制我们只能加载同样是AOT（或直接由native语言）编译的库。
那么如何实现这种需求呢？好在现在我们有一个现成的成熟技术可以运用：COM（Component Object Model，组件对象模型）。它可以带着.NET运行时使用，也可以直接使用C++/IDL这种native语言编写，并且完全面向对象，简直就是为了AOT的插件系统而设计的技术（虽然它甚至比.NET/C#更老）。
在软件关闭时存储设置是每一个软件必需的功能。在WPF中可以通过Settings.settings文件指定，但设置存储的位置很难确定，这不是一个好方法。
在WinUI 3里也有一套自带的设置系统，我们可以方便地使用它来存储用户自定义的设置。
WASDK1.6中，更新了Microsoft.Windows.Storage.ApplicationDataContainerAPI，以取代从旧版UWP继承来的Windows.Storage.ApplicationDataContainer。
区别在于Microsoft.*命名空间下的API较新，而且支持非打包应用。
而且新的ApplicationDataContainerAPI不支持漫游设置，这是由于Win11不支持了（所以旧版的API支持也是有名无实了），MSDN建议使用Azure 应用服务代替。
WinUI 3中，几乎所有与Fluent Design样式的控件，都是通过资源字典（ResourceDictionary）中的样式（Style）来指定的。这就为我们自定义控件的样式提供了可能。
更好的消息是在WASDK1.4后的版本里，样式部分已经全面开源了，就在github的microsoft-ui-xaml仓库中。
WinUI 3作为一个新式桌面应用框架，还有很多方面需要打磨，崩溃错误也是频发的。
在使用IDE调试（Debug模式）过程中，异常大都会被编译器捕捉并被我们看见，也就是几乎不需要我们手动收集。
但一旦进入生产环境（Release模式）时，就会出现这些问题：
使用MVVM框架时，属性的赋值顺序一直都是令人头疼的点。
一方面希望参数赋值一步到位，以减少OneWay绑定的使用；
另一方面若顺序搞错了，后果轻则属性获得空值，可能需要触发PropertyChanged才能更新，
重则直接调用了null成员，直接导致程序崩溃。
所以本文我们通过实验的方法进行探讨，XAML的赋值顺序和事件的触发顺序是什么样的。
首先我们需要明确，到底有多少内容需要分析。经过整理，得到以下内容：
事件和方法：
写过任何桌面应用，尤其是WinForm的朋友们应该见过，Main函数上放置了一个[STAThread]的Attribute。
而且几乎所有的桌面应用框架，都是由同一个UI线程来执行渲染操作的，这表现为从其他线程修改控件的值就会抛异常：
await Task.Run(() => control.Content = ""); // throws exceptionImageSource相关类型是最常用的API之一，用来在界面中展示图片。
但从WPF开始，我就一直分不清ImageSource、BitmapImage、Bitmap的区别。
甚至还因为它们名称带“Source”，错认为“Source”类才是承载图片的源、核心，现在看来真是大错特错了。
本文将会纠正这些概念。
首先请看WinUI 3中ImageSource相关的类型继承表。
首先先要理解何为“Source”才好对这些类型做个初步的印象。