I did not even think about that, thank you for the idea. It's really easy, just have to find the time for these settings. I recently ran with problem, of some dll file was missed, I should reinstall it again, I used a vcruntime140.dll download https://fix4dll.com/vcruntime140_dll, from my partner advice, and you know kind of perfect match. I mean, convenient service to solving such problems.
13 March 2018 at 08:52
Something else noticed whilst developing my C++/CLI ActiveX control.
I'm using the CRT (v9.0) and for deployment I'm shipping the DLLs as private assemblies (i.e. 'xcopy deployment'). However what I noticed is that the embedded manifest inside my DLL was pointing toward version 9.0.210228.8 of the CRT, when the actual DLLs in the redist folder (which I'm using for packaging) are the SP1 version of the CRT (v9.0.30729.1).
Problem is, if the target installation PC doesn't already have the SP1 Visual C++ 2008 Redistributable SP1 package installed, then the runtime probe will fallback to my private assembly, however, because my private assembly version is 9.0.30729.1 but the manifest is asking for 9.0.210228.8 then we get a load failure.
Solution is to add a #define into the source (stdafx.h) to tell Visual Studio to generate a manifest which points to the current vclibs installed for the development environment (i.e. 9.0.30729.1):-
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1
"Visual Studio embedded manfiest targetting 9.0.21022.8 CRT even though 9.0.30729.1 (SP1) is in the redist"
1 Comment -
I did not even think about that, thank you for the idea. It's really easy, just have to find the time for these settings. I recently ran with problem, of some dll file was missed, I should reinstall it again, I used a vcruntime140.dll download https://fix4dll.com/vcruntime140_dll, from my partner advice, and you know kind of perfect match. I mean, convenient service to solving such problems.
13 March 2018 at 08:52