Update Wix v3.14 to Wix v6 (Setup and SetupBundle) #1378
Conversation
There was a problem hiding this comment.
Pull request overview
This PR migrates the WiX installer projects from the legacy WiX Toolset v3.14 to WiX v6, converting the projects to SDK-style format with NuGet package references. The migration also includes fixes for C++ runtime dependency issues on older Windows 10 builds and improves developer experience with automatic signtool.exe detection.
Changes:
- Converted
.wixprojfiles to SDK-style projects using WixToolset.Sdk/6.0.2 - Updated all WiX source files (.wxs, .wxl, .xslt) from v3 to v4 schema namespaces
- Implemented auto-detection of signtool.exe from Windows SDK registry
Reviewed changes
Copilot reviewed 15 out of 15 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| SetupBundle/SetupBundle.wixproj | Migrated to SDK-style project with NuGet packages and auto-detection for signtool |
| SetupBundle/Bundle.wxs | Updated namespace to v4, changed from Product to Package, hardcoded version and manufacturer |
| SetupBundle/VisualCppRuntime.wxs | Migrated to v4 schema with ExePackagePayload structure |
| SetupBundle/DotNetFramework.wxs | Updated namespace and attribute names for v4 compatibility |
| SetupBundle/Resources/Theme.wxl | Converted from element content to Value attributes for v4 |
| Setup/Setup.wixproj | Migrated to SDK-style with HarvestDirectory items for automated component generation |
| Setup/Product.wxs | Changed from Product to Package element with v4 namespace |
| Setup/Directories.wxs | Updated to use StandardDirectory for v4 compatibility |
| Setup/Shortcuts.wxs | Updated namespace to v4 |
| Setup/LegacyCleanup.wxs | Updated namespace to v4 |
| Setup/Components/*.wxs | Updated namespaces to v4 |
| Setup/Components/Application.xslt | Updated namespace and improved file reference syntax |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| </BootstrapperApplication> | ||
|
|
||
| <Chain> | ||
| <PackageGroupRef Id="NetFx48Web" /> |
There was a problem hiding this comment.
The PackageGroupRef references 'NetFx48Web' but the PackageGroup defined in DotNetFramework.wxs has Id='DotNetFramework'. This mismatch will cause a build error. Change this to <PackageGroupRef Id=\"DotNetFramework\" /> to match the actual PackageGroup definition.
| <PackageGroupRef Id="NetFx48Web" /> | |
| <PackageGroupRef Id="DotNetFramework" /> |
| </BootstrapperApplication> | ||
|
|
||
| <Chain> | ||
| <PackageGroupRef Id="NetFx48Web" /> |
There was a problem hiding this comment.
The VisualCppRuntime PackageGroup is defined in VisualCppRuntime.wxs but is not referenced in the Chain. According to the PR description, one of the key goals is to fix startup crashes on older Windows 10 builds caused by missing C++ runtime dependencies. The VisualCppRuntime must be included in the installation chain. Add <PackageGroupRef Id=\"VisualCppRuntime\" /> before the MsiPackage elements.
| <PackageGroupRef Id="NetFx48Web" /> | |
| <PackageGroupRef Id="NetFx48Web" /> | |
| <PackageGroupRef Id="VisualCppRuntime" /> |
| <PackageGroupRef Id="DotNetFramework" /> | ||
| <PackageGroupRef Id="VisualCppRuntime" /> | ||
| <MsiPackage Id="SetupX64" | ||
| Version="3.8.0"> |
There was a problem hiding this comment.
The version is hardcoded to '3.8.0' instead of being dynamically bound from the MSI package. In the original code, this used !(bind.packageVersion.SetupX86) to extract the version from the MSI. With the hardcoded version, any changes to the application version will require manual updates here. Consider using a preprocessor variable or binding to maintain version consistency.
| Version="3.8.0"> | |
| Version="!(bind.packageVersion.SetupX86)"> |
| <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration> | ||
| <Platform Condition=" '$(Platform)' == '' ">x64</Platform> |
There was a problem hiding this comment.
The Setup project now defaults to x64 and only includes PropertyGroup configurations for Debug|x64 and Release|x64 (lines 11-17), but the Bundle.wxs still references both x86 and x64 MSI packages (SetupX86 and SetupX64). The x86 platform support has been removed from Setup.wixproj, which will cause the build to fail when SetupBundle tries to include the non-existent x86 MSI. Either restore x86 platform configurations or remove the SetupX86 reference from Bundle.wxs.
| </Target> | ||
|
|
||
| <Target Name="PreBuild" BeforeTargets="PreBuildEvent"> | ||
| <Exec Command="IF NOT EXIST "C:\Temp" ( mkdir "C:\Temp" )
curl "https://go.microsoft.com/fwlink/%3fLinkId=2085155" -L -o "C:\Temp\ndp48-web.exe"
curl "https://go.microsoft.com/fwlink/%3fLinkId=2124703" -L -o "C:\Temp\MicrosoftEdgeWebview2Setup.exe"" /> |
There was a problem hiding this comment.
The PreBuild target uses a hardcoded path C:\Temp for downloading dependencies. This path could conflict with other software or be blocked by security policies on some build machines. Consider using
| <Bundle Name="Safe Exam Browser" | ||
| IconSourceFile="$(var.Setup.ProjectDir)Resources\Application.ico" | ||
| Manufacturer="!(bind.packageManufacturer.SetupX86)" | ||
| Manufacturer="ETH Zurich" |
There was a problem hiding this comment.
The Manufacturer has been changed from the dynamic binding !(bind.packageManufacturer.SetupX86) to the hardcoded value 'ETH Zurich'. While this matches the value in Product.wxs, using hardcoded values creates a maintenance burden and risks inconsistency if the manufacturer name is updated in one place but not the other. The original binding approach was more maintainable.
| Manufacturer="ETH Zurich" | |
| Manufacturer="!(bind.packageManufacturer.SetupX86)" |
| <wix:RegistryValue Value="URL:Safe Exam Browser Protocol" Type="string" /> | ||
| <wix:RegistryValue Name="URL Protocol" Value="" Type="string" /> | ||
| <wix:RegistryValue Key="DefaultIcon" Value="[#ApplicationIconFile]" Type="string" /> | ||
| <wix:RegistryValue Key="shell\open\command" Value=""[#MainExecutable]" "%1"" Type="string" /> |
There was a problem hiding this comment.
The registry value was changed from [ApplicationDirectory]$(var.SafeExamBrowser.Runtime.TargetFileName) to [#MainExecutable]. While [#MainExecutable] is a valid file reference in WiX v4, this change alters the path resolution. The original used a directory property plus filename variable, while the new version uses a file identifier. Verify this produces the correct full path, as the file identifier syntax may expand differently than the directory + filename approach.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1378 +/- ##
==========================================
+ Coverage 52.23% 52.24% +0.01%
==========================================
Files 265 265
Lines 14498 14498
Branches 1589 1589
==========================================
+ Hits 7573 7575 +2
+ Misses 6624 6622 -2
Partials 301 301 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Thanks for your contribution! We have (already for quite some time) a task in our backlog with the aim to update to the latest available WiX Toolset version.
CORRECTION: The task has meanwhile been moved at the top of the backlog and the changes should, given your generous contribution, be most likely be able to be integrated in version 3.12.0. |
|
Thank you for the update! It is great to hear that this contribution helps prioritize the migration task. I completely understand the roadmap for 3.11.0. I am happy to see this slated for version 3.12.0. If you need any adjustments or rebases when the time comes to integrate these changes, just let me know. |
|
Thanks a lot, it is much appreciated indeed. We'll definitely let you know if so and will report back once a development build is ready for testing. |
2 participants
Description
This PR migrates the installer projects (
SetupandSetupBundle) from the legacy WiX v3.14 to the modern WiX Toolset v6.Key Changes
1. WiX v6 Migration:
.wixprojfiles to SDK-style projects (WixToolset.Sdk/6.0.2).WixToolset.UI.wixext,WixToolset.Bal.wixext,WixToolset.NetFx.wixext).3. Build Improvements:
signtool.exevia Windows SDK registry keys. Developers no longer need to manually addsigntoolto their System PATH environment variable.Verification