I found out, that the cblite.dll was not able to load MSVCP140.dll, VCRuntime140_1.dll and VCRuntime140.dll.
Does this mean that I need to install the Visual C++ Runtime? This surprises me a bit because it wasn’t mentioned in the documentation.
Yes, you need to have the runtime installed. It’s something that is almost always installed anyway which is probably why the documentation was missed.
On .NET, incidentally, I check for it and throw an exception if it is not there to tell users that they need it.
Have you considered embedding the runtime into the DLL?
We distribute our application as a standalone package without external dependencies, and this approach is integral to our strategy. Distributing the cblite.dll was already problematic. Not embedding the runtime into the DLL would introduce dependencies that compromises this strategy.
Yes I have considered and rejected that approach. There are way too many issues with it for my liking. Microsoft’s own advice is to use the vc++ redist at install time. If I bundle it, then I am essentially declaring that I want all other native libraries loaded into the same process to use specifically this version of the runtime. If that runtime is older than the one that any of the other components used then suddenly there is a risk of very hard to explain instability and crashing.
JVM vendors recently ran into this exact problem when 14.40 was released:
If your application is truly standalone then feel free to bundle the runtime along with it (Microsoft has some guidance on how to get the correct one for shipping), but this is not a new dependency. We have depended on this since 2.0.
I think I see that you potentially mean “static linking” when you say “embedding”. I’ve looked into that as well and it seems to be generally frowned upon too. In general on any OS it’s not great to have multiple versions of a C or C++ runtime loaded into a single process.