Renew and Modernize WeaselSetup

[WhiredPlanck]

理由：

1. 现有的代码稍显繁杂，且大量使用了 Win32 API 提供的各种函数和类型，降低了现代性、可读性和维护性
2. Setup 不强依赖其他子组件，经过翻新后，其可以独立编译
3. 选择使用 .NET 及 C#，两者是微软官推和支持的产品，如同 Kotlin 之于 Android，遇到问题同样容易找到解决的方法
4. C# 能简化 C++ 编写时需要的范式和模式

几点差异：

1. 名称由 WeaselSetup 改为 Weasel.Setup，一是遵守一般 C# 项目的命名规范，二是为了和前者区分开。
2. 移除了安装旧版 IME 支持的选项，文本服务框架（TSF）自 Windows XP 上市，已诞生 20 年有余。目前小狼毫已最低支持 Windows 8.1，或许也没必要再考虑旧版 IME 的支持。
3. 目前无法强制开启 HiDPI 支持。需要在同目录的 Weasel.Setup.config 里进行配置。但正式发行时这个文件一般不携带。（已解决）
4. 产物中会附带 TSF.TypeLib.dll，这是 C# 下的 TSF 绑定库。
5. 由于 xmake 目前不支持 C#，如果构建方式选择 xmake，需要单独进行编译。（已解决）

Reasons:

1. The existing code is somewhat complex and makes extensive use of various functions and types provided by the Win32 API, which reduces modernity, readability, and maintainability.
2. Setup does not strongly depend on other sub-components. After renovation, it can be compiled independently.
3. The choice to use .NET and C# is made because they are officially promoted and supported by Microsoft, similar to Kotlin for Android. When encountering problems, solutions can be found more easily.
4. C# can simplify the paradigms and patterns required when writing in C++.

Diffirences:

1. Rename WeaselSetup to Weasel.Setup, one reason is to comply with the naming specification of common C# project, another reason is to distinguish from the former.
2. Option to add legacy IME support has been removed. Text Service Framework (TSF) has been around for more than 20 years since Windows XP hit the market. We may no need to consider the legacy IME support anymore, since Weasel minimal support OS is Windows 8.1.
3. Currently it cannot force enable HiDPI support. It requires to set in Weasel.Setup.config in the same directory, while the latter will not be included in common release. (Solved)
4. A C# TSF binding library TSF.TypeLib.dll will appear in the output.
5. People need to build it separately in xmake way since xmake doesn't support C# yet. (Solved)

[fxliang]

不懂，ARM相关的找下之前pr的大神看方便不方便帮测试下

[WhiredPlanck]

不懂，ARM相关的找下之前pr的大神看方便不方便帮测试下

@driver1998

[driver1998]

.NET Framework AnyCPU 程序只要在项目设置里允许ARM64就可以在Windows 11上原生运行，现在VS有个一键开关：
https://devblogs.microsoft.com/visualstudio/how-to-run-net-apps-natively-on-arm64-devices/

我记得之前WeaselSetup依赖了RIME的库，如果没打算编译ARM64的RIME的话保持WeaselSetup x86（32位或64位）是最好的。

Win10只支持32位x86的.NET。

[WhiredPlanck]

.NET Framework AnyCPU 程序只要在项目设置里允许ARM64就可以在Windows 11上原生运行，现在VS有个一键开关： https://devblogs.microsoft.com/visualstudio/how-to-run-net-apps-natively-on-arm64-devices/

我记得之前WeaselSetup依赖了RIME的库，如果没打算编译ARM64的RIME的话保持WeaselSetup x86（32位或64位）是最好的。

Win10只支持32位x86的.NET。

这个一键开关我已经打开了，那应该没问题。新版的 setup 程序没有向外依赖了，只额外通过 NuGet 安装了一个 TSF 绑定库用于注册或注销输入法服务（其也是 AnyCPU 的）。我本机是 Windows 10 22H2（x86_64），已测试没问题。

[fxliang]

这个pr等其他组件一并考虑，待观察，先让ci跑了

[WhiredPlanck]

这个pr等其他组件一并考虑，待观察，先让ci跑了

那提交历史得多长呀，肯定分步来吧 🌚

[fxliang]

这个pr等其他组件一并考虑，待观察，先让ci跑了

那提交历史得多长呀，肯定分步来吧 🌚

长是必然的

另外提交多了某种程度就是理由1，2的反面了

[WhiredPlanck]

这个pr等其他组件一并考虑，待观察，先让ci跑了

那提交历史得多长呀，肯定分步来吧 🌚

长是必然的

另外提交多了某种程度就是理由1，2的反面了

我的意思是一个 PR 只干一个子组件的事情，不然审阅也是个麻烦呀 …… 总之一个 PR 就把整个软件翻新是不合理的，除非只有一个子组件。

[fxliang]

我的意思不是一个pr，是n个互不冲突的pr。

语言这换种的事情，天然注定不可能轻易做的。

[WhiredPlanck]

我的意思不是一个pr，是n个互不冲突的pr。

语言这换种的事情，天然注定不可能轻易做的。

具体这个 PR 来说比较容易（小声：隔壁 rabbit 甚至还是 ahk 写的呢） …… 还是等 @lotem 有空来把关吧。

[fxliang]

必然是全组件可c#写，而且确认没有问题才能换的，毕竟现在又不是不能用

删除ime这个目前我保留意见

[driver1998]

老设备更新24H2之后SysARM32目录依然是存在的，不过是空的
你可以考虑用IsWow64GuestMachineSupported API（就是这个API要1709，需要考虑API不存在的情况），也可以考虑判断sysarm32\regsvr32.exe是否存在（反正待会儿就要用）

[WhiredPlanck]

@driver1998 我在你的博客上看到了相关文章：

1. https://driver1998.github.io/posts/net-framework-apps-on-windows-arm64/
2. https://driver1998.github.io/posts/arm32-deprecation-what-does-that-mean/

这么看来 .NET Framework 可能还不太适合干这个工作？

[driver1998]

这么看来 .NET Framework 可能还不太适合干这个工作？

Windows 10 和老版本的 11 确实没有好的办法原生运行 (使用AnyCPU的话)，但原来 C++ 的 WeaselSetup 也是模拟运行的，所以没差