重要
已过时,仅Visual Studio 2022需要此操作,新版Visual Studio 2026内置的PowerShell已经自带命令补全(PSReadLine)
如果你下载了Windows Terminal和最新版的PowerShell Core就会发现,
如果不特殊设置的话,即使我们使用的Windows Terminal拥有命令补全,Visual Studio 2022的终端仍然没有任何补全。


重要
已过时,仅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 exception
ImageSource相关类型是最常用的API之一,用来在界面中展示图片。
但从WPF开始,我就一直分不清ImageSource、BitmapImage、Bitmap的区别。
甚至还因为它们名称带“Source”,错认为“Source”类才是承载图片的源、核心,现在看来真是大错特错了。
本文将会纠正这些概念。
首先请看WinUI 3中ImageSource相关的类型继承表。
首先先要理解何为“Source”才好对这些类型做个初步的印象。
现代新式应用设计中,图标常常占有和说明性文字同等重要的地位,为了选择和自己应用风格一致、且有足够数量的图标库常常让人很伤脑筋。
好在WinUI系列提供一套官方的图标库——Segoe Fluent Icons,和Fluent Design十分匹配,可以在Gallery中Design guidance/Iconography选项找到图标预览。