I am working on a C++ application that uses many DLLs. I am migrating the application to build with the Windows 10 SDK.

After I thought I had successfully rebuilt all DLLs and the EXE to use the Windows 10 SDK, when I attempt to run the program, I get this error message:

The error message as text:

Mismatch between the program and library build versions detected.

The library used 2.9.4 (wchar_t,Visual C++ 1942,wx containers,compatible with 2.8),

and your program used 2.9.4 (wchar_t,Visual C++ 1943,wx containers,compatible with 2.8),

From comparing the information on the library and "the program", the only difference that I see is that the library uses Visual C++ 1942 and "the program" uses Visual C++ 1943. I assume in this context, "the program" means the EXE.

I have two questions:

1. How can I build a DLL with Visual C++ 1943? I have never heard of Visual C++ 1943 before, so I don't know if it is referring to the MSVC version, the platform toolset value used to build, or something else that I need to change.
2. As there are many DLLs that the EXE uses, how can I identify which DLL was built with Visual C++ 1942?

I am working on a C++ application that uses many DLLs. I am migrating the application to build with the Windows 10 SDK.

After I thought I had successfully rebuilt all DLLs and the EXE to use the Windows 10 SDK, when I attempt to run the program, I get this error message:

The error message as text:

Mismatch between the program and library build versions detected.

The library used 2.9.4 (wchar_t,Visual C++ 1942,wx containers,compatible with 2.8),

and your program used 2.9.4 (wchar_t,Visual C++ 1943,wx containers,compatible with 2.8),

From comparing the information on the library and "the program", the only difference that I see is that the library uses Visual C++ 1942 and "the program" uses Visual C++ 1943. I assume in this context, "the program" means the EXE.

I have two questions:

1. How can I build a DLL with Visual C++ 1943? I have never heard of Visual C++ 1943 before, so I don't know if it is referring to the MSVC version, the platform toolset value used to build, or something else that I need to change.
2. As there are many DLLs that the EXE uses, how can I identify which DLL was built with Visual C++ 1942?

• c++
• windows
• winapi
• dll
• wxwidgets

Share Improve this question Follow edited Feb 27 at 12:40 PaulMcKenzie 35.5k44 gold badges2626 silver badges4848 bronze badges asked Feb 27 at 12:16 Shane BishopShane Bishop 4,86244 gold badges2929 silver badges6666 bronze badges 5

• 4 Visual C++ 1942 -- See the Microsoft documentation on _MSC_VER. – PaulMcKenzie Commented Feb 27 at 12:29
• 2 how can I identify which DLL was built with Visual C++ 1942? -- That error message was made up by "wxwidgets", and probably baked into the build of that library. The _MSC_VER value cannot be determined by simply looking at a DLL through something like "dumpbin" or "dependency walker". – PaulMcKenzie Commented Feb 27 at 12:37
• @shanebishop, Why did you need to rebuild? wxwidgets team maje everything backward compatible. The only reason to ever rebuild everything is to upgrade wxwidgets which is long overdue... – Igor Commented Feb 27 at 14:00
• On top of answering you question - make sure you copy all dll you rebuilt in the directory where your executable is.... that should fix the issue you are having. – Igor Commented Feb 27 at 14:01
• @Igor, I needed to rebuild in order to build with a Platform Toolset that is compatible with Windows 11. – Shane Bishop Commented Mar 1 at 2:23

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 6

Did you update your MSVS 2022 installation between building wxWidgets libraries and the main program? This is the only explanation for the mismatch that I can see because the _MSC_VER values appearing in the error refer to different minor versions of MSVS 2022.

Of course, if you didn't use a 13 (!) year old wxWidgets version, you wouldn't run into this problem because newer versions (since ~12 year old 3.0.0, I think) don't erroneously consider MSVC versions using the same ABI as being incompatible.