-
Notifications
You must be signed in to change notification settings - Fork 184
Windows build scripts #1224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows build scripts #1224
Conversation
Signed-off-by: Maxime Gervais <gervais.maxime@gmail.com>
|
@cjee21 FYI due to new security requirements for signing, we can not sign anymore on the build machine, we need to export the binary to the signature machine, reason we separate the build from the packaging (we manage the signature with another workflow between the 2 calls), so for the moment sign.cmd does not work anymore, we are looking for a way to do that. |
|
@JeromeMartinez, noted. One way is probably to try splitting the uninstaller generation from the main NSIS script. Then build all binaries including uninstaller and sign everything then build the final installer and sign that again. |
|
btw, does the new CLI build script work? It does not work on my local machine due to this line: MSBuild "/p:Configuration=Release;Platform=${arch}" "/t:MediaInfo-CLI" MediaInfo.sln Changing MediaInfo-CLI to MediaInfo works. If it works on build machine then it's okay, maybe due to me using MSVC2026, I can just do a find/replace when wanting to use the script. MSBuild /restore "/p:RestorePackagesConfig=true;Configuration=Release;Platform=${arch}" "/t:MediaInfo_WindowsShellExtension" MediaInfo.sln will likely fail during nuget restore if wxwidgets repo is not present as well. Can use slnf solution filter from #1214 to filter out the wxwidgets projects if necessary. If your build machine will always have wxwidgets repo then it is not an issue (only an issue if others want to use the script and do not want to obtain wxwidgets that they do not need). Also for newer scripts, I think |
|
Building only a subset of the solution using -t: seems to work on our build server (VS2022): |
|
On MSVC2026 targeting For the shell extension, if wxWidgets repository is not available, targeting just the shell extension will still fail during package restore. If I remember correctly, this also happens on MSVC2022. If it works on your build server then it's fine. Just note that other users may encounter this (depending on their system / presence of wxWidgets repo) if they want to use the scripts. |
|
I tested with MSVC2022 on GitHub Actions: https://github.com/cjee21/MediaInfo/actions/runs/21437735410/job/61732558785 So targeting MediaInfo-CLI works on MSVC2022 but not MSVC2026 so not an issue. Targeting shell extension only does not work on MSVC2022 too if wxWidgets projects are missing. Not an issue if your build server will always have the wxWidgets projects. |
|
wxWidgets isn't installed on our build server... The solution with VS2026's slnx seems to be using paths: -t:CLI/MediaInfo.vcxproj (untested) |
It should be same between solutions, what is different?
Is it possible to avoid that? |
I am not sure why, in MSVC2026, targeting
My proposed solution is to use this: #1214
But I assume you are building from |
Looks like it is due to how msbuild parses slnx files. For MSVC2026, I switch sln files to the newer XML-based slnx because it is smaller, more readable, supposedly faster to parse and results in less diff when making changes to projects. In sln files there is the project name |
I am file with renaming the project file. |
I'll make a PR to switch to the slnf solution |
Possible solution to still sign the uninstaller: https://nsis.sourceforge.io/Signing_an_Uninstaller_externally |
No description provided.