Today, we install Microsoft.VisualStudio.Component.VC.Tools.x86.x64 into our build tools. This includes the latest version of the C++ compiler. That moving target causes several types of problems:
A few VC versions are not compatible with UE. There's a risk that future VC versions suddenly fail as well.
VC obj/lib/pdb files are forward compatible, but not necessarily backward compatible. If the prebuilt Engine version uses a new VC version, then anyone who wishes to use that version and build Game code must be on that VC version or a newer one. Because of this, VC upgrades in the build system force developers to update the VC version on their workstations.
Managing the build system becomes more difficult; if we want to fix a specific problem with the Windows builders, and this requires rebuilding VM images / Docker buildtools images, then the rebuild will also update VC to the latest version. This forces the above knock-on effects. It's preferable to have explicit control over the VC version.
Locking the VC version is reasonably straightforward: We should replace the VC tools Workload with the necessary components instead - but make sure to lock any components that we can. See the Workloads and Component IDs for reference.
We should probably standardize on a VC version for now. v16.11 is the final servicing release for MSVC 2019, we should pick that.
Note, this will only lock the C++ compiler versions, and will lock major+minor, but not servicing release. Other bits (like C# compiler) remain a moving target I think. To lock that, we would need to save the exact boostrap installer (vs_buildtools.exe) used - but MS only makes the most recent publicly available, older versions are allegedly possible to download from my.visualstudio.com but that requires logging in first. The bootstrap installer furthermore supports a --channelUri argument, through which we could force a different installation manifest -- but again, where do we get older manifests?
Another option would be to regularly fetch the vs_buildtools.exe package and create an archive of offline installers that way. Still, however... this is silly.
Today, we install
Microsoft.VisualStudio.Component.VC.Tools.x86.x64
into our build tools. This includes the latest version of the C++ compiler. That moving target causes several types of problems:Locking the VC version is reasonably straightforward: We should replace the VC tools Workload with the necessary components instead - but make sure to lock any components that we can. See the Workloads and Component IDs for reference.
We should probably standardize on a VC version for now. v16.11 is the final servicing release for MSVC 2019, we should pick that.
Note, this will only lock the C++ compiler versions, and will lock major+minor, but not servicing release. Other bits (like C# compiler) remain a moving target I think. To lock that, we would need to save the exact boostrap installer (
vs_buildtools.exe
) used - but MS only makes the most recent publicly available, older versions are allegedly possible to download from my.visualstudio.com but that requires logging in first. The bootstrap installer furthermore supports a--channelUri
argument, through which we could force a different installation manifest -- but again, where do we get older manifests?Another option would be to regularly fetch the
vs_buildtools.exe
package and create an archive of offline installers that way. Still, however... this is silly.