Codecov Report

Attention: Patch coverage is 0% with 4 lines in your changes missing coverage. Please review.

Project coverage is 47.56%. Comparing base (6f1a94e) to head (309ff2d).
Report is 4 commits behind head on develop.

@@             Coverage Diff             @@
##           develop     #242      +/-   ##
===========================================
- Coverage    48.77%   47.56%   -1.22%     
===========================================
  Files          220      220              
  Lines        12654    12649       -5     
  Branches      1224     1223       -1     
===========================================
- Hits          6172     6016     -156     
- Misses        6168     6326     +158     
+ Partials       314      307       -7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

https://learn.microsoft.com/en-us/azure/trusted-signing/how-to-signing-integrations suggests that the minimum signtool version is 22621 and the dlib requires net8 - are you using an old version of the dlib intentionally, requiring an older signtool and net6?

(ppy said you were using signtool 22000 and you said your dlib is on net6)

Released in https://github.com/velopack/velopack/releases/tag/0.0.630-g9c52e40

I also noticed that the MSFT article lists .NET 8. My observation comes from downloading the nupkg (as listed in the article) and inspecting the .dll + the .runtimeconfig, both listing that it was built against .NET 6.0. For instance:

{
  "runtimeOptions": {
    "tfm": "net6.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "6.0.0"
    },
    "rollForward": "Major",
    "configProperties": {
      "System.Globalization.Invariant": true,
      "System.Reflection.Metadata.MetadataUpdater.IsSupported": false
    }
  }
}

And yes, the irony of the major rollforward is not lost on me here... That being said, the DLL is a mishmash of both native and managed components - it doesn't look to be quite NativeAOT, which may explain the rollforward not actually working here (and why it requires a system install of .NET). I dunno...

But at the very least, we're using the latest available version of the dlib.

requiring an older signtool

We ran into issues using Velopack's included signtool with the dlib: https://melatonin.dev/blog/code-signing-on-windows-with-azure-trusted-signing/#comment-13954, so we changed to using the signtool included via the Windows SDK on the runner. According to https://github.com/actions/runner-images/blob/main/images/windows/Windows2022-Readme.md, this would be 10.0.22621.0

That was a result of looking around at how other projects are doing the same thing, and noticing gh-cli: https://github.com/cli/cli/blob/5be59997d31d3207148f5e8a8608882976471253/script/sign.ps1#L13-L17

Another noteworthy discovery is also that the GitHub action mentioned in that article downloads specifically the 22621 version of Microsoft.Windows.SDK.BuildTools that includes the signtool.

I wasn't really involved in the "how or why" of the above - I only suggested doing what other projects do and use the Windows SDK, so I haven't looked into whether VPK's signtool is newer or older than required to result in the issue... (Though I've been told VPK's comes from the Win11 SDK?)

I wasn't really involved in the "how or why" of the above - I only suggested doing what other projects do and use the Windows SDK, so I haven't looked into whether VPK's signtool is newer or older than required to result in the issue... (Though I've been told VPK's comes from the Win11 SDK?)

We ship signtool x64 10.0.22621 from the windows sdk, that's correct.