Day 5 - 版本与发布
建议用时:180-210 分钟
你将学会什么
- 理解版本号
1.0.0的含义 - 区分
Debug和Release - 区分框架依赖发布和自包含发布
- 使用
dotnet publish生成发布目录 - 写清发布说明和发布检查记录
发布不是只执行一条命令。发布包含版本号、构建模式、目标系统、发布目录、发布说明、发布后验证。缺少任何一环,都容易出现“开发电脑能跑,换一台电脑就打不开”的问题。
本页固定顺序
- 先学第一部分:弄懂今天最小、最重要的知识,并运行短例子。
- 再学第二部分:把刚学的知识组合成一个完整例子。
- 然后做第三部分:自己跟着敲,再完成重复训练和每日小测。
- 最后做第四部分:先独立完成作业,再用完整答案检查。
今天只抓住 3 件事
- 发布前必须用
Release构建,不只看dotnet run。 - 发布产物要有版本号、目录、说明和验证记录。
- 目标系统不同,发布命令和运行要求也可能不同。
学习衔接
上一页学习的是“文档完善”,今天继续学习“版本与发布”。先使用上一页已经会的写法,再只增加今天这个新知识点;如果前置内容还不能独立敲出,先回上一页复习,不要硬跳。
第一部分:先学原理和最小知识
这一部分只读,不敲代码。
版本号是什么
常见版本号写成:
主版本.次版本.修订版本例如:
1.0.0含义可以这样记:
| 位置 | 名称 | 什么时候改 |
|---|---|---|
1 | 主版本 | 大范围变化,旧用法可能不兼容 |
0 | 次版本 | 增加功能,但原有用法基本不变 |
0 | 修订版本 | 修 bug、小调整、文档修正 |
例子:
1.0.0:第一个正式版本。1.1.0:增加了新功能。1.1.1:修了 bug。2.0.0:做了大改动。
Debug 和 Release 的区别
| 模式 | 用途 | 特点 |
|---|---|---|
Debug | 开发时使用 | 更方便调试,包含更多调试信息 |
Release | 发布时使用 | 更适合交付,编译结果更接近真实运行环境 |
开发时用:
dotnet run发布前用:
dotnet build -c Release
dotnet publish -c Release不能只验证 Debug,因为 Release 才是交给别人运行的版本。
框架依赖发布和自包含发布
| 发布方式 | 命令特点 | 用户机器要求 | 发布目录大小 |
|---|---|---|---|
| 框架依赖发布 | 不加 --self-contained true | 用户机器需要安装 .NET Runtime | 较小 |
| 自包含发布 | 加 --self-contained true | 用户机器通常不需要单独安装 Runtime | 较大 |
先学习时,建议先用框架依赖发布,因为命令短、目录小、验证快。
真正交付给不懂开发环境的人时,可以考虑自包含发布。
RID 是什么
RID 是 Runtime Identifier,表示目标系统。
常见 RID:
| 系统 | RID |
|---|---|
| macOS Apple Silicon | osx-arm64 |
| macOS Intel | osx-x64 |
| Windows 64 位 | win-x64 |
| Linux 64 位 | linux-x64 |
如果你在 macOS Apple Silicon 上发布给 Windows 用户,不能只用默认发布目录,要指定 win-x64。
发布说明写什么
发布说明不是随便写一句“发布了”。它至少回答:
- 版本号是多少。
- 发布日期是哪一天。
- 新增了什么。
- 修复了什么。
- 怎么运行。
- 有哪些已知问题。
第二部分:把知识组合成完整例子
今天要把项目从“开发状态”整理成“可以交付的发布产物”。
最终要得到这些东西:
artifacts/
ProductManager-1.0.0/
可执行程序和依赖文件
VERSION.txt
RELEASE_NOTES_1.0.0.md其中:
artifacts/ProductManager-1.0.0/是发布目录。VERSION.txt只写当前版本号,方便快速确认。RELEASE_NOTES_1.0.0.md写本次发布包含什么、修复什么、还有什么已知问题。
先看最小发布命令
dotnet publish -c Release -o ./artifacts/ProductManager-1.0.0这条命令的意思是:
publish:生成发布产物。-c Release:使用 Release 模式。-o ./artifacts/ProductManager-1.0.0:把发布结果放到指定目录。
第三部分:跟着做一次发布
从这里开始动手。下面以 ProductManager 为项目名,版本号使用 1.0.0。
第 1 步:在项目文件里写版本号
打开 Avalonia 应用的 .csproj 文件,在第一个 <PropertyGroup> 里面加入版本信息。
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net8.0</TargetFramework>
<Nullable>enable</Nullable>
<BuiltInComInteropSupport>true</BuiltInComInteropSupport>
<ApplicationManifest>app.manifest</ApplicationManifest>
<AvaloniaUseCompiledBindingsByDefault>true</AvaloniaUseCompiledBindingsByDefault>
<Version>1.0.0</Version>
<AssemblyVersion>1.0.0.0</AssemblyVersion>
<FileVersion>1.0.0.0</FileVersion>
<InformationalVersion>1.0.0</InformationalVersion>
</PropertyGroup>如果你的 .csproj 里已有一些属性,不需要完全一样,只要把这 4 行版本信息放进去即可:
<Version>1.0.0</Version>
<AssemblyVersion>1.0.0.0</AssemblyVersion>
<FileVersion>1.0.0.0</FileVersion>
<InformationalVersion>1.0.0</InformationalVersion>第 2 步:写 VERSION.txt
在项目根目录创建 VERSION.txt。
1.0.0这个文件很简单,但很实用。以后打开项目不用翻 .csproj,直接看它就知道当前版本。
第 3 步:发布前先构建
先执行:
dotnet restore
dotnet build -c Release如果项目里有测试项目,再执行:
dotnet test发布前先构建,是为了提前发现编译错误。不要等发布命令执行到一半才发现代码没通过。
第 4 步:生成本机发布目录
执行:
dotnet publish -c Release -o ./artifacts/ProductManager-1.0.0发布成功后,检查目录:
artifacts/ProductManager-1.0.0/里面应该能看到:
- 可执行文件。
.dll文件。- 依赖文件。
- 运行时配置文件,例如
.runtimeconfig.json。
第 5 步:按目标系统发布
如果要指定系统,可以使用 RID。
macOS Apple Silicon:
dotnet publish -c Release -r osx-arm64 --self-contained true -o ./artifacts/ProductManager-1.0.0-osx-arm64Windows 64 位:
dotnet publish -c Release -r win-x64 --self-contained true -o ./artifacts/ProductManager-1.0.0-win-x64Linux 64 位:
dotnet publish -c Release -r linux-x64 --self-contained true -o ./artifacts/ProductManager-1.0.0-linux-x64先在当前电脑验证本机发布,再考虑跨系统发布。跨系统发布生成了文件,不等于已经在目标系统运行验证过。
第 6 步:写发布说明
创建 RELEASE_NOTES_1.0.0.md。
# ProductManager 1.0.0 发布说明
发布日期:2026-06-12
## 本次发布内容
- 新增商品列表。
- 新增商品创建、编辑、删除功能。
- 新增商品搜索和筛选功能。
- 新增本地 JSON 保存。
- 新增 CSV 导入和导出。
- 新增操作日志。
- 新增角色权限判断。
- 新增发布检查清单。
## 本次修复
- 修复商品名称为空时仍可保存的问题。
- 修复价格小于等于 0 时提示不清楚的问题。
- 修复保存中重复点击导致重复提交的问题。
## 运行方式
1. 解压发布目录。
2. 打开发布目录。
3. 运行可执行文件。
## 已知问题
- CSV 导入失败时,当前只显示失败数量,暂时不显示每一行失败原因。
- 数据当前保存在本地文件,多台电脑之间不会自动同步。
- 删除商品后暂时不能一键撤销。
## 验证记录
- `dotnet restore` 已通过。
- `dotnet build -c Release` 已通过。
- `dotnet publish -c Release` 已通过。
- 新增、编辑、删除、搜索、保存已经手动验证。第 7 步:发布后检查
发布目录生成后,按下面顺序检查:
- 发布目录存在。
- 发布目录里有可执行文件。
- 在发布目录中启动程序。
- 新增一个商品。
- 关闭程序,再打开,确认数据还在。
- 测试搜索、编辑、删除。
- 查看日志目录是否能写入。
- 把本次结果写进发布说明或检查清单。
发布常用命令速查
| 需求 | 命令 | 说明 |
|---|---|---|
| 还原依赖 | dotnet restore | 下载项目需要的 NuGet 包 |
| Debug 运行 | dotnet run | 开发时快速运行 |
| Release 构建 | dotnet build -c Release | 发布前检查 |
| 本机发布 | dotnet publish -c Release -o ./artifacts/ProductManager-1.0.0 | 输出发布目录 |
| Windows 自包含 | dotnet publish -c Release -r win-x64 --self-contained true | 用户不需要单独装 Runtime |
| macOS Intel 自包含 | dotnet publish -c Release -r osx-x64 --self-contained true | 发布给 Intel macOS |
| macOS Apple Silicon 自包含 | dotnet publish -c Release -r osx-arm64 --self-contained true | 发布给 Apple Silicon macOS |
| 查看 SDK | dotnet --version | 检查开发环境 |
常见错误和修法
| 错误 | 为什么错 | 修法 |
|---|---|---|
| 只用 Debug 验证 | Debug 和 Release 结果可能不同 | 发布前跑 dotnet build -c Release |
| 发布目录没写版本号 | 多个版本容易混在一起 | 目录名带版本,例如 ProductManager-1.0.0 |
| 不写 RID | 不清楚目标系统 | 按目标系统选择 win-x64、osx-x64 等 |
| 自包含发布目录很大 | Runtime 被一起打包了 | 这是正常现象,换来用户机器少装依赖 |
| 发布说明没有验证记录 | 不知道这个版本检查过什么 | 写清执行命令和检查结果 |
小白重复敲写训练
版本发布要反复练“改版本、构建、打标签前检查”。
训练 1:设置正式版本
<PropertyGroup>
<Version>1.0.0</Version>
<AssemblyVersion>1.0.0.0</AssemblyVersion>
<FileVersion>1.0.0.0</FileVersion>
</PropertyGroup>训练 2:在程序中读取版本
string version = typeof(Program).Assembly
.GetName()
.Version?
.ToString() ?? "unknown";
Console.WriteLine(version);训练 3:发布前完整命令
dotnet clean
dotnet restore
dotnet build -c Release
dotnet test -c Release
dotnet publish -c Release -o artifacts/1.0.0第三遍把版本改成 1.0.1,说明它表示哪一类变更。
每日小测
做完本页后,用这 5 题检查是否真的掌握。
1. 判断题
本页的目标不是只把代码运行起来,还要能说清楚“为什么这样写”。
答案:对。能运行只是第一步,能解释原理、常用操作和常见错误,才说明本页内容进入了可复用能力。
2. 填空题
本页主题是:版本与发布。今天至少要掌握的 3 个点是:
1. 理解版本号 `1.0.0` 的含义
2. 区分 `Debug` 和 `Release`
3. 区分框架依赖发布和自包含发布答案:以上 3 点必须能用自己的代码跑通,不能只停留在阅读。
3. 流程题
遇到本页相关功能时,先按什么顺序处理?
答案:先看完整例子,确认最终效果;再读原理和名词;然后跟着第三部分从空项目敲代码;最后对照作业答案检查。
4. 找错误题
如果本页代码运行失败,第一步应该做什么?
答案:先看终端或 IDE 里的第一条错误,找到文件名和行号;不要同时改很多地方。再回到本页的“常见错误和修法”表格,对照错误类型逐项排查。
5. 改需求题
在本页完整例子跑通后,至少改一个小需求。
可选改法:
- 改一个字段名称。
- 多加一个校验条件。
- 多输出一行结果。
- 把固定数据改成用户输入。
- 把一次处理改成多条数据处理。
答案标准:修改后能重新运行,并能说明这次修改影响了哪一段逻辑。重点检查:理解版本号 1.0.0 的含义。
上位机专项练习
版本发布要可重复:版本号、变更记录、构建命令、发布包和校验值都能追踪。
下面 3 个例子都要亲手敲。先运行原代码,再完成每个例子后面的改动任务。
专项例子 1:设置语义版本
<PropertyGroup>
<Version>1.0.0</Version>
<AssemblyVersion>1.0.0.0</AssemblyVersion>
<FileVersion>1.0.0.0</FileVersion>
</PropertyGroup>运行结果或界面效果:
应用和文件都显示 1.0.0改动任务: 修复 bug 时改成 1.0.1。
专项例子 2:固定发布命令
dotnet test -c Release
dotnet publish src/Hmi.App -c Release -r win-x64 --self-contained true
tar -a -c -f Hmi.App-1.0.0-win-x64.zip -C publish .运行结果或界面效果:
测试、发布、打包顺序固定改动任务: 把命令写进 release.ps1。
专项例子 3:发布目录命名
releases/
1.0.0/
Hmi.App-1.0.0-win-x64.zip
SHA256.txt
release-notes.md运行结果或界面效果:
每个版本有独立完整资料改动任务: 生成 1.0.1 示例目录。
第四部分:作业完整答案
作业要求
整理一个完整的 1.0.1 修复版本发布材料,内容包括:
- 版本号。
- 发布目录命令。
- 发布说明。
- 发布前检查清单。
完整答案:VERSION.txt
1.0.1完整答案:发布命令
dotnet restore
dotnet build -c Release
dotnet publish -c Release -o ./artifacts/ProductManager-1.0.1如果发布给 macOS Apple Silicon:
dotnet publish -c Release -r osx-arm64 --self-contained true -o ./artifacts/ProductManager-1.0.1-osx-arm64完整答案:RELEASE_NOTES_1.0.1.md
# ProductManager 1.0.1 发布说明
发布日期:2026-06-12
## 本次发布内容
- 这是 `1.0.0` 之后的修复版本。
## 本次修复
- 修复保存失败时错误提示不够明确的问题。
- 修复空列表时页面没有提示的问题。
- 修复发布说明缺少已知问题的问题。
## 运行方式
1. 解压发布目录。
2. 打开发布目录。
3. 运行可执行文件。
## 已知问题
- CSV 导入失败时,暂时只显示失败数量。
- 删除商品后暂时不能一键撤销。
## 验证记录
- `dotnet restore` 已通过。
- `dotnet build -c Release` 已通过。
- `dotnet publish -c Release` 已通过。
- 已验证新增商品。
- 已验证空名称错误提示。
- 已验证空列表提示。完整答案:发布前检查清单
# ProductManager 1.0.1 发布前检查清单
- [ ] 版本号已经改为 `1.0.1`。
- [ ] `VERSION.txt` 已经改为 `1.0.1`。
- [ ] `dotnet restore` 执行成功。
- [ ] `dotnet build -c Release` 执行成功。
- [ ] `dotnet publish -c Release` 执行成功。
- [ ] 发布目录存在。
- [ ] 发布目录里有可执行文件。
- [ ] 新增商品功能已验证。
- [ ] 空名称错误提示已验证。
- [ ] 空列表提示已验证。
- [ ] 发布说明已经更新。正确结果
完成后,你应该能清楚回答:
- 当前发布版本是多少。
- 发布目录在哪里。
- 本次版本新增了什么。
- 本次版本修复了什么。
- 发布前检查过哪些命令。
- 还有哪些已知问题。