如何基于VB.NET开发可部署至Windows与macOS的跨平台应用

分支策略调整 #

• 完全没必要为Windows、macOS分别创建独立的生产/调试分支，.NET 6+ 统一SDK原生支持跨平台编译，拆分分支会导致后续功能迭代、Bug修复需要在两个分支重复同步，维护成本会随着版本迭代快速失控
• 采用单主干分支维护全量代码，通过条件编译常量、平台特定实现层隔离不同平台的差异逻辑即可，调试时根据当前运行环境自动加载对应实现，不需要切换分支。

VB.NET跨平台适配前提 #

• 首先明确版本选型：必须选.NET 6/8 这类LTS版本，.NET Framework是Windows专属，完全无法在macOS运行，直接排除
• UI框架不要选WinForms、WPF，这两个目前仅支持Windows平台，直接选Avalonia UI即可，它原生支持VB.NET开发，同时兼容Windows、Intel/Apple Silicon架构macOS、Linux平台，API设计和WPF相似度很高，VB.NET开发者上手成本极低
• 平台差异逻辑处理：把系统调用、文件操作、硬件交互这类不同平台实现逻辑不一致的部分抽成公共接口，Windows和macOS的具体实现分别放在独立的类库中，主项目通过编译配置按需引用对应平台的实现，不要把平台判断逻辑散落在业务代码里。

macOS平台部署落地步骤 #

• 编译阶段
  日常开发完全可以在Windows设备上完成，不需要提前采购Mac设备，业务逻辑调试可以先在Windows端完成，编译跨平台包直接使用dotnet publish命令，指定macOS对应的运行时标识（RID）即可：
  • Intel架构Mac包编译命令：
    dotnet publish -c Release -r osx-x64 --self-contained true /p:PublishSingleFile=true
  • Apple Silicon（M系列）架构Mac包编译命令：
    dotnet publish -c Release -r osx-arm64 --self-contained true /p:PublishSingleFile=true
    加--self-contained true参数会把.NET运行时一起打包，用户端不需要单独安装.NET环境就能运行。
• 应用打包
  不要直接把编译出的二进制文件发给用户，需要按照macOS规范打包成.app格式的应用包：按固定目录结构放置可执行文件、资源文件，编写Info.plist配置文件声明应用名称、版本号、所需系统权限即可。如果需要简化分发，可以用lipo工具把Intel和Arm架构的二进制合并成通用包，一个安装包就能适配所有型号Mac。
• 签名与分发
  如果是企业内部使用，不需要额外购买苹果开发者账号，直接给用户说明打开方式：右键点击应用选择「打开」，确认系统安全提示即可正常运行；如果是公开发布，申请苹果开发者账号后对.app包做代码签名，提交苹果公证服务审核通过后，用户打开时就不会触发系统安全拦截。
• 调试适配
  如果需要调试macOS端专属功能，可以用macOS虚拟机做测试环境，或者采购低成本的Mac mini作为专门的构建测试机，不需要把主力开发设备换成Mac。

常见避坑点 #

• 路径处理不要硬编码Windows专属的\分隔符，统一用Path.Combine()方法做路径拼接，避免在macOS上出现路径找不到的错误
• 不要直接调用Win32、注册表这类Windows专属系统API，这类调用在macOS上会直接抛出运行时异常，系统相关能力优先用成熟的跨平台封装库，或者通过之前提到的平台实现层做适配
• 不要默认系统自带Windows端常见的字体、命令行工具，这类依赖如果业务需要，要随应用包一起分发
• 文本编码、换行符这类细节要统一用跨平台默认配置，不要硬编码Windows专属的GBK编码、\r\n换行符，避免出现文件读取乱码问题。

内容的提问来源于stack exchange，提问作者Byte