如何通过MSBuild调用仓库内置非IDE版Delphi编译器构建应用？

核心设计目标 #

将应用构建全流程依赖的所有资源（业务源码、静态资源、编译器组件、构建脚本）统一归集到代码仓库内，实现完全自包含、跨环境一致的可复现构建，彻底消除不同构建节点因为Delphi安装版本、配置差异导致的构建产物不一致问题。

待验证的核心落地场景 #

• 基于Docker镜像搭建预装MSBuild的标准化构建执行环境
• 在Delphi业务代码仓库中，完整托管对应版本的Delphi编译器全量组件（包含bin、lib等核心运行目录）
• 构建节点拉取仓库代码后，可直接通过MSBuild触发应用构建流程，且编译过程调用的编译器为仓库内置版本，完全规避系统级安装的Delphi IDE默认编译器的干扰

选型逻辑说明 #

选择MSBuild作为统一构建入口，而非直接调用dcc命令编译.dpr工程文件，核心原因是：

• MSBuild可原生解析.dproj格式的Delphi工程配置，完整保留项目内配置的搜索路径、条件编译规则、组件依赖引用等全量构建信息
• 规避直接编译.dpr文件时，因为构建配置信息缺失导致的产物偏差、构建失败问题

落地可行性判定 #

这套方案完全可以落地，没有本质层面的阻碍，落地过程仅需要做好三个关键约束即可：

• 配置MSBuild的Delphi编译器路径参数时，强制指向仓库内的编译器可执行文件路径，不依赖系统环境变量的默认路径映射
• 提前在工程配置中把仓库内置的lib目录设置为最高优先级的搜索路径，避免编译时意外引用到系统级Delphi安装目录下、版本不匹配的依赖库
• Docker基础镜像仅需要预装满足MSBuild运行要求的.NET Framework运行时，配置好MSBuild的全局可执行路径即可，无需在镜像内预装任何版本的Delphi IDE，既缩小镜像体积，也从根源上避免系统级编译器的干扰

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