Skip to Content
Week 12Day 5 - 版本与发布

Day 5 - 版本与发布

建议用时:180-210 分钟

你将学会什么

  • 理解版本号 1.0.0 的含义
  • 区分 DebugRelease
  • 区分框架依赖发布和自包含发布
  • 使用 dotnet publish 生成发布目录
  • 写清发布说明和发布检查记录

发布不是只执行一条命令。发布包含版本号、构建模式、目标系统、发布目录、发布说明、发布后验证。缺少任何一环,都容易出现“开发电脑能跑,换一台电脑就打不开”的问题。

本页固定顺序

  1. 先学第一部分:弄懂今天最小、最重要的知识,并运行短例子。
  2. 再学第二部分:把刚学的知识组合成一个完整例子。
  3. 然后做第三部分:自己跟着敲,再完成重复训练和每日小测。
  4. 最后做第四部分:先独立完成作业,再用完整答案检查。

今天只抓住 3 件事

  1. 发布前必须用 Release 构建,不只看 dotnet run
  2. 发布产物要有版本号、目录、说明和验证记录。
  3. 目标系统不同,发布命令和运行要求也可能不同。

学习衔接

上一页学习的是“文档完善”,今天继续学习“版本与发布”。先使用上一页已经会的写法,再只增加今天这个新知识点;如果前置内容还不能独立敲出,先回上一页复习,不要硬跳。

第一部分:先学原理和最小知识

这一部分只读,不敲代码。

版本号是什么

常见版本号写成:

主版本.次版本.修订版本

例如:

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 Siliconosx-arm64
macOS Intelosx-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-arm64

Windows 64 位:

dotnet publish -c Release -r win-x64 --self-contained true -o ./artifacts/ProductManager-1.0.0-win-x64

Linux 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 步:发布后检查

发布目录生成后,按下面顺序检查:

  1. 发布目录存在。
  2. 发布目录里有可执行文件。
  3. 在发布目录中启动程序。
  4. 新增一个商品。
  5. 关闭程序,再打开,确认数据还在。
  6. 测试搜索、编辑、删除。
  7. 查看日志目录是否能写入。
  8. 把本次结果写进发布说明或检查清单。

发布常用命令速查

需求命令说明
还原依赖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
查看 SDKdotnet --version检查开发环境

常见错误和修法

错误为什么错修法
只用 Debug 验证Debug 和 Release 结果可能不同发布前跑 dotnet build -c Release
发布目录没写版本号多个版本容易混在一起目录名带版本,例如 ProductManager-1.0.0
不写 RID不清楚目标系统按目标系统选择 win-x64osx-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` 执行成功。 - [ ] 发布目录存在。 - [ ] 发布目录里有可执行文件。 - [ ] 新增商品功能已验证。 - [ ] 空名称错误提示已验证。 - [ ] 空列表提示已验证。 - [ ] 发布说明已经更新。

正确结果

完成后,你应该能清楚回答:

  • 当前发布版本是多少。
  • 发布目录在哪里。
  • 本次版本新增了什么。
  • 本次版本修复了什么。
  • 发布前检查过哪些命令。
  • 还有哪些已知问题。