自动构建与自动更新

本文记录的方法不是 WinUI 3 专属的，也可以用于其他框架。

某不能说名字的软件在开发时需要频繁更新版本，为了兼顾开发体验和用户体验，使用自动化流程达到这一目的。

自动构建#

代码托管在 GitHub 上，使用 GitHub Actions 是最合适的选择。在写自动构建的流程之前，考虑了这么几个问题：

1. GitHub 在部分地区速度太慢或不可用，不适合作为安装包的下载来源，选择了白嫖阿里云 OSS 和 Cloudflare 代理。
2. 为了区分自动构建的版本和发行版，需要在版本号后加上 -dev.*，选择了在文件的 ProductVersion 属性中记录当前版本号。

准备环境#

运行 Actions 的系统为 windows-latest，默认 Shell 为 PowerShell。

- name: Checkout
  uses: actions/checkout@v3
  with:
    # 迁出所有代码，后面有用
    fetch-depth: 0

- name: Install .NET Core
  uses: actions/setup-dotnet@v3
  with:
    dotnet-version: 7.0.x

- name: Restore the Packages
  run: dotnet restore

# 配置 阿里云 OssUtil
- name: Setup Aliyun OssUtil
  run: |
    # 见下方 PowerShell 代码块

# 下载适合 Windows 的 OssUtil 安装包到临时文件夹
Invoke-WebRequest https://gosspublic.alicdn.com/ossutil/1.7.14/ossutil64.zip -OutFile ${{runner.temp}}/ossutil.zip
# 解压
Expand-Archive -Path ${{runner.temp}}/ossutil.zip -DestinationPath ${{runner.temp}}
# 把 exe 文件移动到 system32 文件夹下，为了在后续步骤中可以直接使用 ossutil 命令
Move-Item -Path ${{runner.temp}}/ossutil64/ossutil64.exe -Destination C:/Windows/System32/ossutil.exe -Force
# 配置账号
ossutil config -e ${{ secrets.OSS_ENDPOINT }} -i ${{ secrets.ACCESS_KEY_ID }} -k ${{ secrets.ACCESS_KEY_SECRET }}

版本号#

每次构建的版本必须比上一次构建的版本要大，可以通过当前时间生成版本 v1.2.3-dev.221015.2201，或者通过环境变量 ${{github.run_number}} 获取当前 Action 是第几次执行，就是 Actions 页面每次执行时 # 后面的那个数字。但是这两个方法生成的版本号是一直递增的，我比较倾向于使用 上个版本发布后的提交数 作为 -dev. 后的数字。

下面是生成目标版本号的函数，可以不用看

function Get-TargetVersion {
    # 获取上一个 tag，迁出代码时设置 fetch-depth: 0
    $lastTag = git describe --abbrev=0 --tags
    if ([String]::IsNullOrWhiteSpace($lastTag)) {
        # 没有 tag
        $lastTag = 'v0.1.0'
        # 提交次数
        $commitCount = git rev-list HEAD --count
    }else {
        # 有 tag
        $commitCount = git rev-list "$lastTag..HEAD" --count
    }
    # 把 tag 开头的 v 去掉
    if ($lastTag.StartsWith('v') -or $lastTag.StartsWith('V')) {
        $lastTag = $lastTag.SubString(1)
    }
    # 引入一个新库 NuGet.Versioning
    $null = [System.Reflection.Assembly]::LoadFrom('NuGet.Versioning.dll')
    # TryParse 方法中使用 out 修饰的参数必须先定义
    [ref]$lastVer = [NuGet.Versioning.SemanticVersion]::Parse('0.1.0')
    # 解析上一个版本号，有可能是 v1.2.3、v1.2.3-preview.1 或更复杂的内容
    if ([NuGet.Versioning.SemanticVersion]::TryParse($lastTag, $lastVer)) {
        if ($lastVer.Value.IsPrerelease) {
            # 上个版本是预发行版，直接在后面加上 -dev.*
            $targetVer = "$lastVer-dev.$commitCount"
        }
        else {
            # 上个版本是正式版，版本号+1后再接 -dev.*
            $targetVer = "$($lastVer.Value.Major).$($lastVer.Value.Minor).$($lastVer.Value.Patch+1)-dev.$commitCount"
        }
    }
    else {
        # 理论上来说不会运行到这里
        $targetVer = "$lastVer-dev.$commitCount"
    }
    Write-Output $targetVer
}

在这里使用了一个库 NuGet.Versioning，这是解析 语义化版本 v2.0 一个库，和 System.Version 仅支持 4 个数字不同，它支持解析和比较如 1.2.3-preview.4.5.6+abcdef 这样的格式。

发布#

$v = Get-TargetVersion
dotnet publish -p:Configuration=$env:Configuration -p:Platform=$env:Platform -p:Version=$v -p:DefineConstants=DEV

压缩并上传至 OSS#

使用 zip 压缩后文件大小大约是 60 MB，使用 7zip 则是 40 MB，用户的网络环境不同，能压缩就尽量压缩。在上传到 OSS 时自定义元数据 x-oss-meta-version 为目标版本号，软件可以通过检查这个值判断是否应该更新。

# 安装 7zip 压缩模块
Install-Module -Name 7Zip4Powershell -Scope CurrentUser -Force
New-Item -Path ./publish -ItemType Directory -Force
# 压缩等级最大，压缩时包含根目录
Compress-7Zip -ArchiveFileName software.7z -Path $env:Publish_Path -OutputPath ./publish -CompressionLevel Ultra -PreserveDirectoryRoot
# 上传至 OSS
ossutil cp -rf ./publish/* oss://${{ secrets.OSS_BUCKET_NAME }}/software.7z --meta x-oss-meta-version:$v

自动更新#

非打包的 WinUI 项目和 Win32 项目一样，更新时会遇到文件被占用的情况，一般是通过额外的更新进程解决这个问题。不这么一个小东西要啥自行车，用 PowerShell 一把梭，不仅能规避占用问题，还能少一个项目。

我原本是打算在 PowerShell 中下载新版本安装包的，PowerShell 会自动展示下载进度，但是我发现下载速度始终限制在 1 MB/s 左右，而在浏览器或 C# 中下载速度能够达到 6 MB/s。在网上搜了一圈后发现是 实时显示下载数据量拖慢了性能，参考 Issue Progress bar can significantly impact cmdlet performance，这个问题已在 PowerShell Core 修复，在 Windows 自带的 PowerShell 中仍然存在，唯一的解决办法是禁止显示下载进度。

40 MB 的安装包不显示下载进度还是不太好，只能多写一点代码在软件中下载了（略），下面是 PowerShell 更新脚本代码。

# 出现错误时停止执行后续命令，若不加这一句，即使出现错误也无法被 catch
# 代码省略了最外部的 try-catch 部分
$ErrorActionPreference = 'Stop'
# 检查新版本的安装包是否存在
if(![System.IO.File]::Exists('./temp/software.7z')) {
    # 不存在时重新下载
    $null = New-Item "./temp" -ItemType "Directory" -Force
    Invoke-WebRequest -Uri $url -UseBasicParsing -OutFile "./temp/software.7z"
}
# 检查 7zip 解压模块是否存在
if(![System.IO.File]::Exists('./7Zip4Powershell/7Zip4Powershell.psd1')) {
    # 应该使用下面这一句安装解压模块，但是大陆连接源站 PowerShell Gallery 非常困难
    # Install-Module -Name 7Zip4Powershell -Scope CurrentUser -Force
    # 所以需要自行分发解压模块
    Invoke-WebRequest "url/to/7Zip4Powershell.zip" -UseBasicParsing -OutFile "./7Zip4Powershell.zip"
    Expand-Archive -Path "./7Zip4Powershell.zip" -DestinationPath "./" -Force
    Remove-Item -Path "./7Zip4Powershell.zip" -Force -Recurse
}
# 导入模块
Import-Module -Name "./7Zip4Powershell/7Zip4Powershell.psd1" -Force
# 解压
Expand-7Zip -ArchiveFileName "./temp/software.7z" -TargetPath "./temp/"
# 检查软件是否仍在运行
try {
    # 没找到进程时会抛错，需要 catch
    $null = Get-Process -Name "software"
    Write-Host "software.exe 正在运行，等待进程退出" -ForegroundColor Yellow
    Wait-Process -Name "software"
    # 停 1s 等待资源释放
    Start-Sleep -Seconds 1
} catch { }
# 替换文件
Copy-Item -Path "./temp/*" -Destination "./" -Force -Recurse
# 重启软件
Invoke-Item -Path "./software.exe"
# 清理安装包
Remove-Item -Path "./temp" -Force -Recurse

就这样，使用 PowerShell 代替了额外的更新进程，也不用考虑更新进程需要更新的问题。唯一需要注意的是手动导入的 7zip 解压模块中的文件会被占用，即使使用 Remove-Module 移除模块后，载入的程序集仍不会被卸载，所以不能在安装包中包含该模块，使用前下载最合适，下载后可以一直使用，不用考虑更新问题。

有经验的读者可能会问：哎，系统默认禁用没有签名的 PowerShell 脚本，你总不可能还要让用户手动解除限制吧。这个问题很好解决，不能运行脚本可以运行命令嘛，把脚本内容当作启动参数扔给 PowerShell 进程就好了。

// 这里不是脚本文件路径，而是脚本内容
const string script="...";
Process.Start("PowerShell", script);

最后#

单进程软件真的没办法自己更新吗？其实不然，可执行文件在运行期间无法被删除和覆盖，但是可以移动啊。把 exe 和 dll 文件移动到一个待删除文件夹，这个时候就可以把新文件移动到原来的位置。但是还有个问题，非可执行文件被占用后不能移动，所以还是有可能会更新失败，这个方法能用但是不靠谱。