build: upgrade MSVC platform toolset from v143 to v145 for VS2026

[tpglitch]

Updates all rufus and setup .vcxproj files across the project to use the VS2026 platform toolset (v145).

[tpglitch]

CI fails because the CI still uses VS2022. working on a fix.

[pbatard]

Please fix your PR so that it works with GitHub Actions if you want me to consider it. You should be able to clone this repository and test GitHub Actions in your own clone.

[pbatard]

Since you say you are working on a fix, I will leave this PR open. But I'd prefer if you test CI in your clone first, before we check whether it works on a PR or not.

[tpglitch]

@pbatard as I'm working on this fix, I'm noticing some unrelated issues w/ Coverity that seems completely unrelated to this PR.

[pbatard]

Well, I'm going to need Coverity to work, and incidentally I don't believe that Coverity have upgraded their toolchain for VS2026. Which is one of the many reasons, for established projects, one does not jump into upgrading toolchains as soon as they become available, because there are usually a lot of dependencies that first need to upgrade too, and that we need to wait on... Then again, Coverity had a server upgrade recently, so I wouldn't be surprised if they broke things.

So, unless there is a good reason to drop Coverity, I don't think I will be able to accept this PR just yet...

[pbatard]

By the way, does PlatformToolset=v145 with windows-latest actually use VS2026? Because my understanding is that, if you want VS2026, you need to use windows-2025-vs2026 and not windows-latest.

[tpglitch]

By the way, does PlatformToolset=v145 with windows-latest actually use VS2026?

No, that's why I switched to windows-2026-vs2026.

And coverity is failing because the download site has a 401.

[pbatard]

Can I ask you to merge the multiple commits, so that one doesn't have to go through multiple patches to see what effectively changes? Because I'm seeing one patch where you create a vs2026.yml and still use windows-latest there.

I MUCH PREFER having a forced push/merge that with a single commit, than multiple incremental commits that add one change here and there, especially as I'm going to have to merge them anyway...

[pbatard]

Also Coverity is most likely failing because the download can only work with the private key that is specific to my repository. So please patch Coverity as best as you think you can, keep it in, and then we can see what happens when we run the CI for it here.

[tpglitch]

Yep, I did do that rebase and force push. I don't know if you've refreshed the page for this PR but I did perform a force push. And I patched coverity to the best of my ability and it should work if it does support VS2026.

[pbatard]

Hmm, https://patch-diff.githubusercontent.com/raw/pbatard/rufus/pull/2925.patch shows multiple commits for me [PATCH #/3]. And since Coverity is not being run, I thought you had simply removed it.

Can you add the following to the Coverity YML so it should run of this PR (make it similar to vs####.yml):

  pull_request:
    branches: [master]
    paths-ignore:
      - '.gitignore'
      - '.gitattributes'
      - 'res/**'
      - '**.cmd'
      - '**.md'
      - '**.rc'
      - '**.sh'
      - '**.txt'
      - '**.xml'

[tpglitch]

Oh! You meant everything into one commit. Done!

[pbatard]

coverity.yml is still missing the section I asked you to add above, so it cannot run... Can you please add it?

[tpglitch]

Oops, git didn't track it for some reason. Fixed.

[tpglitch]

Again, Coverity failed for the same reason.

[pbatard]

Yup, I see that. But the URL for the download is valid when logged in, and the token should still be valid.

Especially, you'll see that on the last successful Coverity build, the curl invocation is reported as:

curl -d "token=***&project=pbatard%2Frufus" -L https://scan.coverity.com/download/cxx/win64 -o cov-analysis-win64.zip

Whereas, in the failing build, we see:

curl -d "token=&project=pbatard%2Frufus" -L https://scan.coverity.com/download/cxx/win64 -o cov-analysis-win64.zip

This tells me that, on the PR build, GitHub Actions did not add the necessary secret for the token, which of course will make the download fail.

I guess I'll have to see what happens with Coverity next time I push a commit (that will build with the existing YML) to validate that the downloads do work. Then, I'll have to test a Coverity build locally against VS2026, to see if it can generate the analysis data, as it does with VS2022. And only after that will I try to integrate your patch to see if it works better when ran in the main branch and not in a PR.

At any rate, I will need to upgrade my toolchain locally first, and since this will have implications for other projects, I'm going to have to put this on standby until I am actually ready to ditch VS2022 everywhere. At this stage, I really can't provide a timeline of when all of this is likely to happen. It could be days like it could be months...

[pbatard]

So, whereas the download from their servers should still be fine (when not initiated from a PR), Coverity seems a NO_GO for now, because it looks like they still need to update their toolchain for VS2026:

C:\Projects\rufus>cov-configure --msvc
[WARNING] Template config template-msvc-config-0 already exists for cl and will be reused.
[WARNING] Template config template-msvc_link-config-0 already exists for link and will be reused.
[WARNING] Template config template-msvc_lib-config-0 already exists for lib and will be reused.

Existing configuration is appropriate for the compiler specified and can be reused. New configuration was not generated.

C:\Projects\rufus>cov-build.exe --dir cov-int msbuild rufus.sln /m /p:Configuration=RELEASE,Platform=x64
Coverity Build Capture (64-bit) version 2024.12.1 on Windows 11 Professional, 64-bit (build 26200)
Internal version numbers: 3c60fc625b p-2024.12-push-36

Could not create unique lock file C:/Projects/rufus/cov-int/emit/NUL/emit-db.creation-lock-6f3b58d23067872d6087e6c897965986
[ERROR] Failed to acquire lock "C:\Projects\rufus\cov-int\emit\NUL\emit-db.creation-lock". Unable to protect emit DB creation!

The NUL in there is a dead giveway that something did not resolve properly. Exact same set of commands works fine with VS2022. And yeah, I tried deleting the problematic directory, but no dice.

As such, I am going to have to defer this PR, most likely for a few months, because it doesn't look like the Coverity folks are in a hurry to update their tools...