桌面应用【免费下载链接】SoundSwitchC# application to switch default playing device. Download: https://soundswitch.aaflalo.me/项目地址https://gitcode.com/gh_mirrors/so/SoundSwitch点击查看免费下载本文基于 SoundSwitch 开源仓库根目录下的 AGENTS.md 编写系统梳理该仓库为 AI Agent 与开发者定义的全局协作规范——涵盖技术栈选型、项目结构地图、跨模块代码约定、基于 Conventional Commits 的语义化版本发布规则以及 Windows / Linux 双环境下的构建验证命令。读完本文你将掌握在 SoundSwitch 仓库中提交代码前需要遵守的全部工程约束并能直接复用其验证命令与提交模板。一、Scope这份文档管什么仓库根目录的AGENTS.md是 SoundSwitch 工作区的仓库级repository-wide开发指南为所有在该仓库内工作的开发者包括 AI 编码 Agent定义统一的协作边界。其核心设计是分层覆盖hierarchical override各子目录下更具体的AGENTS.md文件可以在其自身领域内覆盖或扩展根文档的指导例如SoundSwitch/AGENTS.md主 WinForms 应用项目Framework / Model / UI / Localization / Services / Util 六大领域SoundSwitch/Model/AGENTS.md应用模型层AppModel、事件、接口、热键动作SoundSwitch.Common/Framework/Icon/AGENTS.md、SoundSwitch.Audio.Manager/AGENTS.md、SoundSwitch.CLI/AGENTS.md 等各项目与子模块文件因此在动手修改某个模块之前正确做法是先读取仓库根AGENTS.md获取全局约束再读取对应目录下的领域级AGENTS.md获取该模块的专属规则。以 SoundSwitch/Model/AGENTS.md 为例它进一步细化了模型层的变更规则——「新增设置时必须同时接通模型属性、持久化、迁移与运行时消费方」「保持IAppModel与AppModel对齐」「事件 DTO 保持最小逻辑、与序列化无关」。二、Technology技术栈与平台约束根文档明确规定了仓库的技术基线维度约定主语言C#平台Windows 上的 .NETWindows-onlyUI 栈WinForms 桌面应用解决方案入口SoundSwitch.sln该声明与仓库实际配置高度一致global.json 将 .NET SDK 锁定为10.0.401并开启rollForward: latestMajor与allowPrerelease即允许 SDK 向后滚动到更高的主版本构建前提与安装脚本见 docs/building.md。Directory.Build.props 定义了LinuxBuild开关当以-p:LinuxBuildtrue构建时自动设置EnableWindowsTargeting这是后续 Linux 验证命令得以工作的前提。从 docs/building.md 的「Platform Support」一节可确认官方只支持 Windows x64主要与 Windows ARM647.0 起跨平台构建不受支持因为 SoundSwitch 依赖 Core Audio API、WinForms 与 WinAPI 钩子等 Windows 专用 API。对贡献者的含义不要向 WinForms 与 Windows 集成代码中引入跨平台假设任何“在 Linux 上跑通”的做法都只是编译验证不是运行时支持。三、Repository Map仓库地图与职责边界根文档给出了九个核心项目的职责划分这是理解「改动应该落在哪个项目」的索引项目目录职责SoundSwitch/主 WinForms 应用本地化、框架、服务、UI 与应用模型SoundSwitch.Audio.Manager/Windows 音频设备管理与策略切换Core Audio API 集成SoundSwitch.Common/跨项目共享代码SoundSwitch.CLI/命令行入口与自动化面SoundSwitch.IPC/进程间通信组件SoundSwitch.UI.Menu/、SoundSwitch.UI.UserControls/可复用的 UI 组件SoundSwitch.Tests/、SoundSwitch.Audio.Manager.Tests/自动化回归测试覆盖结合 docs/architecture.md 的“Key Layers”可以进一步明确分层职责Framework横幅通知、配置、更新器、托盘集成、WinAPI 适配、Model应用状态、事件、接口与上下文装配、UIWinForms 表单与组件、Services外部集成与业务逻辑、Localization基于 .resx 资源的翻译。该地图蕴含了三条重要的架构原则详见 docs/contributing.md 的 Architecture PrinciplesSoundSwitch.Common/是共享工具唯一的存放位置音频设备管理必须放在SoundSwitch.Audio.Manager/UI 层不得直接调用Windows 音频 APICLI 与 UI 之间的通信必须经由SoundSwitch.IPC/这一层而非直接耦合。四、General Rules跨模块代码约定与源码佐证根文档定义了五条通用规则每条都可以在源码中找到具体实现印证4.1 小步改动优先保持与现有 C#/.NET 代码库风格一致倾向小范围、目标明确的修复而非大规模重构。这与 docs/contributing.md 中「Prefer small, targeted fixes over broad refactors」完全一致。4.2 以 Windows 桌面应用为先避免在 WinForms 与 Windows 集成代码中引入跨平台假设参见上文 Technology 一节。4.3 用户可见字符串必须走本地化资源用户界面文案一律放入本地化资源.resx文件禁止硬编码字符串字面量。仓库SoundSwitch/Localization/下维护了SettingsStrings、AboutStrings、TrayIconStrings、UpdateDownloadStrings四套资源体系每套均包含 30 语言变体如.zh-Hans.resx、.ja-JP.resx并有 Patch-LocalizedResourceDesigners.ps1 负责在构建时修补生成的 Designer 文件。4.4 除非明确意图变更否则保持既有公开行为这是对“行为兼容性”的最低要求与 SoundSwitch/Model/AGENTS.md 的「Preserve event semantics and avoid silent behavior changes」一脉相承也与后文配置迁移的向后兼容要求呼应。4.5 优先使用NameClean而非原始设备名凡涉及音频设备显示名/比较逻辑一律使用NameClean。源码层面的依据清晰可见DeviceInfo.cs 定义了NameClean属性通过NameCleanerRegex正则清洗FriendlyName并拼接DeviceNameName属性被标记为[Obsolete(Use nameof(NameClean))]比较逻辑同样锚定NameClean当Id不同但NameClean相同时仍视为同一设备Equals与GetHashCode均基于Type、NameClean、Id组合DeviceCollection.cs 以${item.Type}-{item.NameClean}作为设备去重键DeviceReadOnlyCollection.cs 的匹配策略文档化说明设备按唯一的NameClean匹配若多个候选共享同一NameClean则不返回匹配、由调用方决策——Ambiguity is reported, never guessed。这一约定也贯穿到子项目SoundSwitch/AGENTS.md中再次强调「UseDeviceFullInfo.NameCleanfor display and comparison logic, neverName」。五、Commits提交规范与语义化版本映射SoundSwitch 使用Conventional Commits但必须遵循仓库自己的 semantic-release 配置位于 package.json 的release字段而不是 generic 的默认规则。这是本文档最值得注意的一点——提交类型直接决定发布的版本号。5.1 版本相关提交类型根文档规定的版本相关类型为feat、fix、perf、lang、boost其效果与 package.json 中semantic-release/commit-analyzer的releaseRules完全对应类型版本影响releaseRules 依据package.jsonfeatminor次版本1{type: feat, release: minor}fixpatch修订版1{type: fix, release: patch}perfpatch{type: perf, release: patch}langpatch翻译更新{type: lang, release: patch}boostpatch性能提升{type: boost, release: patch}revertpatch{revert: true, release: patch}breakingmajor主版本1{breaking: true, release: major}注意几个细节tests类型会被生成在发布说明中但不会单独触发版本发布见release-notes-generator的types配置中包含tests→Tests章节而releaseRules中没有tests条目破坏性变更通过breakingHeaderPattern识别即在类型后追加!如feat(api)!: ...触发 major 版本发布说明的章节映射同样自定义feat→Features、boost→Enhancements、fix→Bug Fixes、lang→Languages、tests→Tests这解释了为什么boost会单独出现在 Enhancement 章节而非并入 perf。5.2 作用域Scope鼓励使用模块式作用域来标注改动区域例如fix(localization): ...、feat(audio-manager): ...。这有助于语义化发布与 CHANGELOG 的可读性也与 docs/contributing.md 中列出的 scope 示例如lang(es-ES): ...表示西班牙语翻译更新一致。5.3 提交信息格式结合 docs/contributing.md 的标准格式type(scope): description [optional body explaining WHY, not what] [optional footer with breaking changes or issue refs]要点body 解释为什么WHY而不是做了什么WHATsubject 保持简洁聚焦用户可见或工程层面的结果。5.4 发布流程如何消费这些提交从 package.json 的发布插件链可以看出端倪semantic-release/commit-analyzer依据上述规则决定下一版本号 →semantic-release/changelog生成 CHANGELOG →semantic-release/exec通过sed更新 AssemblyInfo.cs 中的AssemblyInformationalVersion与AssemblyFileVersion→semantic-release/git提交这两个资产 →semantic-release/github创建 draft Release模板名SoundSwitch v% nextRelease.version %。完整流程见 docs/contributing.md 的 Release Process 一节推送到master/beta触发 release GitHub Action贡献者无需关心版本号。六、Development Documentation开发文档索引根文档将深入阅读指引到docs/目录四篇核心文档构成开发者进阶路径文档主题docs/building.md环境搭建、构建命令与 CI/CD 流水线docs/contributing.md标准、提交约定与 PR 流程docs/architecture.md项目结构与关键分层docs/banner-manager.md麦克风静音横幅子系统的深度剖析其中 docs/building.md 值得单独强调的实操内容与本根文档的 Validation 一节配套一键搭建环境.\tools\Install-BuildTools.ps1安装 .NET SDK、GitHub CLI、Inno Setup 6、代码签名工具与 Python 3命令行构建dotnet build SoundSwitch.sln -c Debug发布构建.\tools\Publish-Release.ps1 -BuildFromSource -Configuration Release生成安装器就绪的Final\目录默认同时产出 win-x64 与 win-arm64 两个安装器可用-Architectures win-x64限制仅安装器构建.\tools\Build-Installer.ps1 -FinalDir .\Final [-SkipSigning]测试dotnet test SoundSwitch.sln -c Debug或分别针对两个测试项目运行。七、ValidationWindows 与 Linux 下的验证命令根文档给出了两类验证命令这是每次改动提交前必须执行的最小门槛7.1 默认验证Windowsdotnet build SoundSwitch.sln -c Debug整解决方案在 Windows 下可直接构建。其背后逻辑可从 docs/building.md 得到印证SoundSwitch.Audio.Manager中的 CsWinRT 投影生成依赖 Windows因此完整的解决方案只能在 Windows 上构建。7.2 Linux 验证编译级检查dotnet build SoundSwitch/SoundSwitch.csproj -c Debug -p:LinuxBuildtrue -p:BuildProjectReferencesfalse根文档解释了为什么 Linux 上不能构建整个解决方案以及这个命令为何安全SoundSwitch.Audio.Manager的 CsWinRT 投影生成要求 WindowsLinuxBuildtrue已在 Directory.Build.props 中定义它启用EnableWindowsTargeting并跳过基于 PowerShell 的PatchLocalizedResourceDesigners预构建目标——跳过是安全的因为修补后的*.Designer.cs文件如 SettingsStrings.Designer.cs已经提交进仓库无需在构建时重新生成BuildProjectReferencesfalse避免在 Linux 上触发无法构建的跨项目引用。7.3 测试验证要求改动所在区域至少运行相关测试项目当改动共享逻辑如SoundSwitch.Common/时至少要运行相关测试项目。Windows 下测试命令为dotnet test SoundSwitch.Tests\SoundSwitch.Tests.csproj dotnet test SoundSwitch.Audio.Manager.Tests\SoundSwitch.Audio.Manager.Tests.csproj测试项目的覆盖方向可从仓库现状佐证SoundSwitch.Tests/覆盖主应用的设备循环、配置迁移、语言回退、主题图标等SoundSwitch.Audio.Manager.Tests/覆盖设备枚举、策略配置、属性存储读取与进程路由切换。八、实战清单一次合规提交的完整路径综合根文档与配套文档在 SoundSwitch 仓库提交代码的完整路径是读规范根AGENTS.md→ 目标目录的领域级AGENTS.md如 SoundSwitch/AGENTS.md定归属按 Repository Map 确定改动落在哪个项目共享代码进SoundSwitch.Common/音频管理进SoundSwitch.Audio.Manager/IPC 走SoundSwitch.IPC/UI 层不直接调 Windows 音频 API守约定小步修改、保持公开行为、UI 文案走.resx、设备名一律用NameCleanSoundSwitch/AGENTS.md额外要求配置变更保持向后兼容并使用Serilog与RailSharp.ResultT既有模式写提交遵循 Conventional Commits类型限定为feat/fix/perf/lang/boost按需加 scope破坏性变更加!正文解释 WHY过验证Windows 下dotnet build SoundSwitch.sln -c Debug 相关测试Linux 下用-p:LinuxBuildtrue -p:BuildProjectReferencesfalse做编译级检查。这套从「技术栈 → 仓库地图 → 编码约定 → 提交类型 → 验证命令」的闭环规范正是 SoundSwitch 能保持多项目、多语言、自动化发布稳定运转的工程基础也是所有贡献者与 AI Agent 在此仓库高效协作的前提。赞分享桌面应用【免费下载链接】SoundSwitchC# application to switch default playing device. Download: https://soundswitch.aaflalo.me/项目地址https://gitcode.com/gh_mirrors/so/SoundSwitch点击查看免费下载相关推荐yazi 仓库 AGENTS.md 开发规范指南Rust 2024 工作区架构、编码约定与验证流程yazi 仓库 AGENTS.md 开发规范指南Rust 2024 工作区架构、编码约定与验证流程 本篇指南以 yazi 仓库根目录的 AGENTS.md h开发工具CLIBlockly 仓库开发指南AGENTS.md 中的工程规范、命令体系与代码约定全解析Blockly 仓库开发指南AGENTS.md 中的工程规范、命令体系与代码约定全解析 本篇技术指南以 Blockly 仓库根目录的 AGENTS.md ht前端低代码UI组件Rufus5 分钟完整制作 USB 启动盘老电脑绕过 TPM 装 Win11Rufus5 分钟完整制作 USB 启动盘老电脑绕过 TPM 装 Win11 Rufus 是一款开源、免费的 USB 格式化工具也是做 USB 启动盘的一桌面应用开发工具上一篇90DaysOfDevOps 第 59 天用 Terraform 与变量在 VirtualBox 中创建虚拟机下一篇如何永久保存你的微信记忆3步实现聊天记录本地化备份与智能分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SoundSwitch 仓库级开发指南：AGENTS.md 中的技术栈、代码规范、提交约定与验证流程全解析
桌面应用【免费下载链接】SoundSwitchC# application to switch default playing device. Download: https://soundswitch.aaflalo.me/项目地址https://gitcode.com/gh_mirrors/so/SoundSwitch点击查看免费下载本文基于 SoundSwitch 开源仓库根目录下的 AGENTS.md 编写系统梳理该仓库为 AI Agent 与开发者定义的全局协作规范——涵盖技术栈选型、项目结构地图、跨模块代码约定、基于 Conventional Commits 的语义化版本发布规则以及 Windows / Linux 双环境下的构建验证命令。读完本文你将掌握在 SoundSwitch 仓库中提交代码前需要遵守的全部工程约束并能直接复用其验证命令与提交模板。一、Scope这份文档管什么仓库根目录的AGENTS.md是 SoundSwitch 工作区的仓库级repository-wide开发指南为所有在该仓库内工作的开发者包括 AI 编码 Agent定义统一的协作边界。其核心设计是分层覆盖hierarchical override各子目录下更具体的AGENTS.md文件可以在其自身领域内覆盖或扩展根文档的指导例如SoundSwitch/AGENTS.md主 WinForms 应用项目Framework / Model / UI / Localization / Services / Util 六大领域SoundSwitch/Model/AGENTS.md应用模型层AppModel、事件、接口、热键动作SoundSwitch.Common/Framework/Icon/AGENTS.md、SoundSwitch.Audio.Manager/AGENTS.md、SoundSwitch.CLI/AGENTS.md 等各项目与子模块文件因此在动手修改某个模块之前正确做法是先读取仓库根AGENTS.md获取全局约束再读取对应目录下的领域级AGENTS.md获取该模块的专属规则。以 SoundSwitch/Model/AGENTS.md 为例它进一步细化了模型层的变更规则——「新增设置时必须同时接通模型属性、持久化、迁移与运行时消费方」「保持IAppModel与AppModel对齐」「事件 DTO 保持最小逻辑、与序列化无关」。二、Technology技术栈与平台约束根文档明确规定了仓库的技术基线维度约定主语言C#平台Windows 上的 .NETWindows-onlyUI 栈WinForms 桌面应用解决方案入口SoundSwitch.sln该声明与仓库实际配置高度一致global.json 将 .NET SDK 锁定为10.0.401并开启rollForward: latestMajor与allowPrerelease即允许 SDK 向后滚动到更高的主版本构建前提与安装脚本见 docs/building.md。Directory.Build.props 定义了LinuxBuild开关当以-p:LinuxBuildtrue构建时自动设置EnableWindowsTargeting这是后续 Linux 验证命令得以工作的前提。从 docs/building.md 的「Platform Support」一节可确认官方只支持 Windows x64主要与 Windows ARM647.0 起跨平台构建不受支持因为 SoundSwitch 依赖 Core Audio API、WinForms 与 WinAPI 钩子等 Windows 专用 API。对贡献者的含义不要向 WinForms 与 Windows 集成代码中引入跨平台假设任何“在 Linux 上跑通”的做法都只是编译验证不是运行时支持。三、Repository Map仓库地图与职责边界根文档给出了九个核心项目的职责划分这是理解「改动应该落在哪个项目」的索引项目目录职责SoundSwitch/主 WinForms 应用本地化、框架、服务、UI 与应用模型SoundSwitch.Audio.Manager/Windows 音频设备管理与策略切换Core Audio API 集成SoundSwitch.Common/跨项目共享代码SoundSwitch.CLI/命令行入口与自动化面SoundSwitch.IPC/进程间通信组件SoundSwitch.UI.Menu/、SoundSwitch.UI.UserControls/可复用的 UI 组件SoundSwitch.Tests/、SoundSwitch.Audio.Manager.Tests/自动化回归测试覆盖结合 docs/architecture.md 的“Key Layers”可以进一步明确分层职责Framework横幅通知、配置、更新器、托盘集成、WinAPI 适配、Model应用状态、事件、接口与上下文装配、UIWinForms 表单与组件、Services外部集成与业务逻辑、Localization基于 .resx 资源的翻译。该地图蕴含了三条重要的架构原则详见 docs/contributing.md 的 Architecture PrinciplesSoundSwitch.Common/是共享工具唯一的存放位置音频设备管理必须放在SoundSwitch.Audio.Manager/UI 层不得直接调用Windows 音频 APICLI 与 UI 之间的通信必须经由SoundSwitch.IPC/这一层而非直接耦合。四、General Rules跨模块代码约定与源码佐证根文档定义了五条通用规则每条都可以在源码中找到具体实现印证4.1 小步改动优先保持与现有 C#/.NET 代码库风格一致倾向小范围、目标明确的修复而非大规模重构。这与 docs/contributing.md 中「Prefer small, targeted fixes over broad refactors」完全一致。4.2 以 Windows 桌面应用为先避免在 WinForms 与 Windows 集成代码中引入跨平台假设参见上文 Technology 一节。4.3 用户可见字符串必须走本地化资源用户界面文案一律放入本地化资源.resx文件禁止硬编码字符串字面量。仓库SoundSwitch/Localization/下维护了SettingsStrings、AboutStrings、TrayIconStrings、UpdateDownloadStrings四套资源体系每套均包含 30 语言变体如.zh-Hans.resx、.ja-JP.resx并有 Patch-LocalizedResourceDesigners.ps1 负责在构建时修补生成的 Designer 文件。4.4 除非明确意图变更否则保持既有公开行为这是对“行为兼容性”的最低要求与 SoundSwitch/Model/AGENTS.md 的「Preserve event semantics and avoid silent behavior changes」一脉相承也与后文配置迁移的向后兼容要求呼应。4.5 优先使用NameClean而非原始设备名凡涉及音频设备显示名/比较逻辑一律使用NameClean。源码层面的依据清晰可见DeviceInfo.cs 定义了NameClean属性通过NameCleanerRegex正则清洗FriendlyName并拼接DeviceNameName属性被标记为[Obsolete(Use nameof(NameClean))]比较逻辑同样锚定NameClean当Id不同但NameClean相同时仍视为同一设备Equals与GetHashCode均基于Type、NameClean、Id组合DeviceCollection.cs 以${item.Type}-{item.NameClean}作为设备去重键DeviceReadOnlyCollection.cs 的匹配策略文档化说明设备按唯一的NameClean匹配若多个候选共享同一NameClean则不返回匹配、由调用方决策——Ambiguity is reported, never guessed。这一约定也贯穿到子项目SoundSwitch/AGENTS.md中再次强调「UseDeviceFullInfo.NameCleanfor display and comparison logic, neverName」。五、Commits提交规范与语义化版本映射SoundSwitch 使用Conventional Commits但必须遵循仓库自己的 semantic-release 配置位于 package.json 的release字段而不是 generic 的默认规则。这是本文档最值得注意的一点——提交类型直接决定发布的版本号。5.1 版本相关提交类型根文档规定的版本相关类型为feat、fix、perf、lang、boost其效果与 package.json 中semantic-release/commit-analyzer的releaseRules完全对应类型版本影响releaseRules 依据package.jsonfeatminor次版本1{type: feat, release: minor}fixpatch修订版1{type: fix, release: patch}perfpatch{type: perf, release: patch}langpatch翻译更新{type: lang, release: patch}boostpatch性能提升{type: boost, release: patch}revertpatch{revert: true, release: patch}breakingmajor主版本1{breaking: true, release: major}注意几个细节tests类型会被生成在发布说明中但不会单独触发版本发布见release-notes-generator的types配置中包含tests→Tests章节而releaseRules中没有tests条目破坏性变更通过breakingHeaderPattern识别即在类型后追加!如feat(api)!: ...触发 major 版本发布说明的章节映射同样自定义feat→Features、boost→Enhancements、fix→Bug Fixes、lang→Languages、tests→Tests这解释了为什么boost会单独出现在 Enhancement 章节而非并入 perf。5.2 作用域Scope鼓励使用模块式作用域来标注改动区域例如fix(localization): ...、feat(audio-manager): ...。这有助于语义化发布与 CHANGELOG 的可读性也与 docs/contributing.md 中列出的 scope 示例如lang(es-ES): ...表示西班牙语翻译更新一致。5.3 提交信息格式结合 docs/contributing.md 的标准格式type(scope): description [optional body explaining WHY, not what] [optional footer with breaking changes or issue refs]要点body 解释为什么WHY而不是做了什么WHATsubject 保持简洁聚焦用户可见或工程层面的结果。5.4 发布流程如何消费这些提交从 package.json 的发布插件链可以看出端倪semantic-release/commit-analyzer依据上述规则决定下一版本号 →semantic-release/changelog生成 CHANGELOG →semantic-release/exec通过sed更新 AssemblyInfo.cs 中的AssemblyInformationalVersion与AssemblyFileVersion→semantic-release/git提交这两个资产 →semantic-release/github创建 draft Release模板名SoundSwitch v% nextRelease.version %。完整流程见 docs/contributing.md 的 Release Process 一节推送到master/beta触发 release GitHub Action贡献者无需关心版本号。六、Development Documentation开发文档索引根文档将深入阅读指引到docs/目录四篇核心文档构成开发者进阶路径文档主题docs/building.md环境搭建、构建命令与 CI/CD 流水线docs/contributing.md标准、提交约定与 PR 流程docs/architecture.md项目结构与关键分层docs/banner-manager.md麦克风静音横幅子系统的深度剖析其中 docs/building.md 值得单独强调的实操内容与本根文档的 Validation 一节配套一键搭建环境.\tools\Install-BuildTools.ps1安装 .NET SDK、GitHub CLI、Inno Setup 6、代码签名工具与 Python 3命令行构建dotnet build SoundSwitch.sln -c Debug发布构建.\tools\Publish-Release.ps1 -BuildFromSource -Configuration Release生成安装器就绪的Final\目录默认同时产出 win-x64 与 win-arm64 两个安装器可用-Architectures win-x64限制仅安装器构建.\tools\Build-Installer.ps1 -FinalDir .\Final [-SkipSigning]测试dotnet test SoundSwitch.sln -c Debug或分别针对两个测试项目运行。七、ValidationWindows 与 Linux 下的验证命令根文档给出了两类验证命令这是每次改动提交前必须执行的最小门槛7.1 默认验证Windowsdotnet build SoundSwitch.sln -c Debug整解决方案在 Windows 下可直接构建。其背后逻辑可从 docs/building.md 得到印证SoundSwitch.Audio.Manager中的 CsWinRT 投影生成依赖 Windows因此完整的解决方案只能在 Windows 上构建。7.2 Linux 验证编译级检查dotnet build SoundSwitch/SoundSwitch.csproj -c Debug -p:LinuxBuildtrue -p:BuildProjectReferencesfalse根文档解释了为什么 Linux 上不能构建整个解决方案以及这个命令为何安全SoundSwitch.Audio.Manager的 CsWinRT 投影生成要求 WindowsLinuxBuildtrue已在 Directory.Build.props 中定义它启用EnableWindowsTargeting并跳过基于 PowerShell 的PatchLocalizedResourceDesigners预构建目标——跳过是安全的因为修补后的*.Designer.cs文件如 SettingsStrings.Designer.cs已经提交进仓库无需在构建时重新生成BuildProjectReferencesfalse避免在 Linux 上触发无法构建的跨项目引用。7.3 测试验证要求改动所在区域至少运行相关测试项目当改动共享逻辑如SoundSwitch.Common/时至少要运行相关测试项目。Windows 下测试命令为dotnet test SoundSwitch.Tests\SoundSwitch.Tests.csproj dotnet test SoundSwitch.Audio.Manager.Tests\SoundSwitch.Audio.Manager.Tests.csproj测试项目的覆盖方向可从仓库现状佐证SoundSwitch.Tests/覆盖主应用的设备循环、配置迁移、语言回退、主题图标等SoundSwitch.Audio.Manager.Tests/覆盖设备枚举、策略配置、属性存储读取与进程路由切换。八、实战清单一次合规提交的完整路径综合根文档与配套文档在 SoundSwitch 仓库提交代码的完整路径是读规范根AGENTS.md→ 目标目录的领域级AGENTS.md如 SoundSwitch/AGENTS.md定归属按 Repository Map 确定改动落在哪个项目共享代码进SoundSwitch.Common/音频管理进SoundSwitch.Audio.Manager/IPC 走SoundSwitch.IPC/UI 层不直接调 Windows 音频 API守约定小步修改、保持公开行为、UI 文案走.resx、设备名一律用NameCleanSoundSwitch/AGENTS.md额外要求配置变更保持向后兼容并使用Serilog与RailSharp.ResultT既有模式写提交遵循 Conventional Commits类型限定为feat/fix/perf/lang/boost按需加 scope破坏性变更加!正文解释 WHY过验证Windows 下dotnet build SoundSwitch.sln -c Debug 相关测试Linux 下用-p:LinuxBuildtrue -p:BuildProjectReferencesfalse做编译级检查。这套从「技术栈 → 仓库地图 → 编码约定 → 提交类型 → 验证命令」的闭环规范正是 SoundSwitch 能保持多项目、多语言、自动化发布稳定运转的工程基础也是所有贡献者与 AI Agent 在此仓库高效协作的前提。赞分享桌面应用【免费下载链接】SoundSwitchC# application to switch default playing device. Download: https://soundswitch.aaflalo.me/项目地址https://gitcode.com/gh_mirrors/so/SoundSwitch点击查看免费下载相关推荐yazi 仓库 AGENTS.md 开发规范指南Rust 2024 工作区架构、编码约定与验证流程yazi 仓库 AGENTS.md 开发规范指南Rust 2024 工作区架构、编码约定与验证流程 本篇指南以 yazi 仓库根目录的 AGENTS.md h开发工具CLIBlockly 仓库开发指南AGENTS.md 中的工程规范、命令体系与代码约定全解析Blockly 仓库开发指南AGENTS.md 中的工程规范、命令体系与代码约定全解析 本篇技术指南以 Blockly 仓库根目录的 AGENTS.md ht前端低代码UI组件Rufus5 分钟完整制作 USB 启动盘老电脑绕过 TPM 装 Win11Rufus5 分钟完整制作 USB 启动盘老电脑绕过 TPM 装 Win11 Rufus 是一款开源、免费的 USB 格式化工具也是做 USB 启动盘的一桌面应用开发工具上一篇90DaysOfDevOps 第 59 天用 Terraform 与变量在 VirtualBox 中创建虚拟机下一篇如何永久保存你的微信记忆3步实现聊天记录本地化备份与智能分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考