Should the MSI installer embed the VC++ DLLs

[gtrevi]

Describe the feature you'd like supported

In moving towards a completely independent install of eBPF for Windows, this ask is to kick off a discussion on whether or not it'd be a good idea to embed the VC++ Redist DLLs within the installer package.

Currently, the installer will only prompt the user to install it, if missing on the system.

Proposed solution

Consolidate a decision to whether or not embed the VC++ Redist DLL within the installer package.

Additional context

Aspects to be explored are:

• Legal
• Maintenace
• Ensuring the correct VC++ Redist DLLs lookup sequence, system wide (i.e. to all other products requiring perhaps other versions)
• Downsides if the VC++ Redist is instead left to the IT to manage (i.e. VM/container baselines, etc.)

[dthaler]

I think the point of a redist is to encourage other packages (like this one) to redist it.
So I would expect the answer to the question to be "yes".

[nibanks]

If you use winget, you can simply add a dependency on those and winget installs them automatically.

[gtrevi]

@dthaler @nibanks

There's also another aspect that must be considered: due to the fact that we now separated the installer features between Debug/Release, the Debug version of the installer requires the debug DLLs of the VC++ Redist, in order to run the eBPF binaries. Those DLLs are not of course distributed and would have to be embedded in the installer package.

[mtfriesen]

Have you considered statically linking to the VC runtime for debug builds? This is what we do for MsQuic and XDP.

[mtfriesen]

Adding some context: XDP plans to take a dependency on eBPF via nuget packages at build time and MSI packages at runtime. We'd like to use debug versions of eBPF binaries with debug builds of XDP to maximize assert coverage and ease debugging, but we do not want to require lightweight test machines to install a full Visual Studio toolchain.

[mtfriesen]

@nibanks pointed me onto a path that could be the best of both worlds for debug builds: statically linking to the CRT, but dynamically linking the UCRT(D) that is provided by, documented by, and serviced by Windows.

    <ClCompile>
      <RuntimeLibrary>MultiThreadedDebug</RuntimeLibrary>
    </ClCompile>
    <Link>
      <AdditionalOptions>/NODEFAULTLIB:libucrtd.lib /DEFAULTLIB:ucrtd.lib</AdditionalOptions>
    </Link>