Closed tristanlabelle closed 11 months ago
CC: @barnson (in case he has any suggestions here)
Perfectly valid lifestyle choice: https://learn.microsoft.com/en-us/cpp/windows/deployment-in-visual-cpp?view=msvc-170#local-deployment The biggest downside, other than the theoretical pain of having to service the DLLs yourselves, is having multiple copies of the DLLs if you have executables in multiple directories. (WiX uses static linking in Burn and custom actions to avoid needing to bootstrap the runtime.)
I'm now using harvesting to make sure we capture all redistributable dlls. Ping for a review!
The Swift runtime depends on the Visual C++ runtime. We currently call the
vcredist.exe
installer, as recommended by Microsoft, but this is a per-machine installer so it makes our per-user installer require elevation. I tried switching to using the vcredist merge modules, but they seem to reference machine-global paths like System64 and it causes build errors. We're left with the option to package the vcruntime dlls directly in the msi. We're not including them in the Swift runtime msm's since application developers may choose to distribute their vcruntime differently.The new
VCRedistDir
property is optional so that this remains backwards compatible with build scripts that don't specify it.Result: