如何利用MSBuild缓存已签名驱动，避免重复签名与不必要重建？

针对你遇到的MSBuild因签名文件变更触发重复重建、无法有效缓存已签名驱动的问题，以下是几个可落地的解决方案：

方案1：分离编译输出与签名输出目录 #

核心思路是让MSBuild仅管理未签名的中间产物，签名后的文件存入独立缓存目录，彻底避免MSBuild修改已签名文件：

• 修改MSBuild项目配置，将编译生成的未签名驱动输出到Intermediate\Unsigned目录（按Windows版本再细分子目录，如Intermediate\Unsigned\Win10）
• 自定义签名脚本从该目录读取文件，签名后输出到Output\Signed对应版本子目录
• 在签名脚本中添加缓存检查逻辑：
  1. 用PowerShell的Get-FileHash计算未签名文件的哈希值
  2. 检查目标缓存目录是否存在已签名文件，以及对应的哈希记录文件（如mydriver.sys.hash）
  3. 如果哈希匹配且signtool verify /pa验证签名有效，则跳过签名步骤
• 批处理主流程优先调用MSBuild编译，再触发签名脚本执行缓存逻辑

方案2：将签名步骤集成到MSBuild增量构建体系 #

把签名、微软提交等步骤转为MSBuild目标，利用其原生增量构建能力识别缓存：

• 在项目文件中新增SignDriver目标，依赖Build目标（确保编译完成后执行签名）：

  <Target Name="SignDriver" AfterTargets="Build" Inputs="$(UnsignedOutputPath)\*.sys;$(OrgCertPath)" Outputs="$(SignedOutputPath)\*.sys">
    <Exec Command="signtool sign /f $(OrgCertPath) /p $(CertPassword) $(UnsignedOutputPath)\*.sys" />
    <Exec Command="copy $(UnsignedOutputPath)\*.sys $(SignedOutputPath) /Y" />
  </Target>
  

• 新增SubmitToMicrosoft目标，针对微软签名流程做增量控制：

  <Target Name="SubmitToMicrosoft" Inputs="$(SignedOutputPath)\*.cab;$(SubmitToolConfig)" Outputs="$(MsSignedOutputPath)\*.cab">
    <Exec Command="cabarc n $(SignedOutputPath)\driver.cab $(SignedOutputPath)\*.sys" />
    <Exec Command="submit_tool.exe $(SignedOutputPath)\driver.cab --config $(SubmitToolConfig)" />
    <Exec Command="download_ms_signed.exe --output $(MsSignedOutputPath)" />
  </Target>
  

• 批处理中直接调用msbuild /t:SubmitToMicrosoft，MSBuild会自动对比输入输出文件的哈希/时间戳，仅在必要时执行操作

方案3：用标记文件记录缓存状态 #

为每个已签名文件生成对应的缓存标记，避免重复处理：

• 签名脚本处理文件前，检查是否存在.sigcache标记文件（如mydriver.sys.sigcache）
• 标记文件内容包含未签名文件的哈希值、签名证书指纹、签名时间
• 脚本逻辑：计算当前未签名文件哈希→对比标记文件记录→若匹配且已签名文件有效则跳过，否则执行签名并更新标记文件
• 针对微软签名后的CAB文件，同样生成.msftsigcache标记，记录提交时的本地CAB哈希，下次构建时若本地CAB未变更则直接复用已下载的双签名CAB

关键注意事项 #

• 绝对不要直接修改MSBuild管理的编译输出文件，否则必然触发增量重建
• 按Windows版本严格隔离缓存目录，避免不同版本驱动混淆
• 缓存时必须校验签名有效性（用signtool verify /pa），防止缓存损坏的签名文件
• 所有缓存逻辑统一写在批处理或MSBuild项目中，确保本地与构建服务器行为完全一致

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