daniatic
commented
1 year ago Disclosure: I'm a developer on the same project.
I wanted to add, that it is not a good idea to add any msvc redistributables to the output binaries, as is done within this library with the vcruntime. The recommended approach for distributing msvc redistributables is to use the correct installer on the executing windows machine. The correct installer depends on the used redistributable version used to build the project and should be at least the same version or higher.
By providing your own vcruntime with the output binaries you dictate which version of the redistributables have to be installed on the executing system instead of the redistributales used to build the project. This leads to discrepancies in several ways:
Due to the backwards compatibility (within 2015-2022 redistributables) it is ok when there is a higher version installed than the project was built with. But I do not believe that this compatibility holds when the deployed vcruntime is of a different version as the rest of the installed msvc.
Secondly, if the project already requires msvc dependencies your approach breaks them as stated above by @Stoffelche.
Could you please explain why you added the vcruntime in the first place and do not stick to the recommended approach, that they need to be present on the executing system by running the correct installer?
We are deploying a windows x64 software, which uses kafka as well as google or-tools. Since adding kafka to the distribution, we experience problems starting google or-tools on certain target machines, where before kafka was included, it worked. I think the problem is related to the fact, that librdkafka includes an incomplete vcruntime 140. I found, that when google ortools is loaded, first vcruntime140.dll is loaded and then vcruntime140_1.dll is loaded as well. Before including kafka in our distribution both dlls were loaded from windows/system32. But now, as vcruntime140.dll is included automatically through the kafka nuget package, this dll is loaded from our application folder, while vcruntime140_1.dll is still loaded from windows/system32 as it is not present in the application folder. However, on some windows installation there are quite old versions of the vc-runtime and my guess is, that the old vcruntime140_1.dll is not compatible with the newer version of vcruntime140.dll, that comes with kafka. Thus I think, you should either include all vc runtime files with your nuget package, or none at all. But a partial include automatically leads to mix-ups of vc runtime dlls which is not desirable. I could confirm the problem, as after adding the missing runtime dlls to our application folder the problem disappeared.