none
Mixing Visual Studio toolkit version RRS feed

  • Question

  • Hi to everyone,

    I have two dynamic linking library with different toolkit version using visual studio 2015. For Ex: A.dll (v90) and B.dll (v140).   I'm invoking the exported functions in B.dll from A.dll. For ex:

    B.dll

    void Test_b_dll() {}

    A.dll

    void Test_a_dll() {

        Test_b_dll();

    }

    The application was able to compile and run in developer system.  But when try to run the application fresh OS, I was not able to load the dll.  When I try to debug using dependency walker, i got architecture mismatch error.

    Why I'm getting architecture mismatch? Is there any problem in application architecture design?


    MIB

    Wednesday, October 9, 2019 2:00 PM

All replies

  • Hello, 

    >Why I'm getting architecture mismatch?

    Most likelly you have x86 application (or used dll) and try to access from it to something in x64 dll.

    Which one is x86 and which one are x64 need to check on your system.

    >Is there any problem in application architecture design?

    Yes. a lot of them... 


    Sincerely, Highly skilled coding monkey.

    Wednesday, October 9, 2019 2:18 PM
  • Thanks for your reply.

    1) Both DLL are build as x86 based and the application involving those dll are also build with x86 based architecture.

    2) Actually I'm trying to mix up the toolkit, to include the latest C++ support.  Since there are many DLL compiled with older toolkit, I would not be able to compile it with newer version.  So that is the reason why I'm trying to compile change with latest toolkit and try to invoke the function in the library created with older toolkit. 


    MIB

    Thursday, October 10, 2019 6:03 AM
  • >Both DLL

    I didn't say that problem is in one of DLL's you build. Any other DLL can call the same issue,.

    And, if you do not known - Studio is 32-bit application. Everithing what used MUST be 32-bit...

    There also can be problem with DLL-signing - some time it resolve to architecture mismatch... but this reare...


    Sincerely, Highly skilled coding monkey.

    Thursday, October 10, 2019 8:11 AM
  • Actually I was able run the application in Developer System, but while running in fresh system, I was getting the issue.  Can you tell us the possibility for including the latest c++ support in older toolkit?

    MIB

    Thursday, October 10, 2019 10:10 AM
  • I work with old Oracle database.
    There are several types of connectivity which can be ussed.
    I have to use an Oracle.DataAccess.dll.

    Problem is that I have about 5-6 versions of this DLL.
    Some of them are x86, other is x64.

    And, YES, on development system I use to build BOTH x64 and x86 applications.
    They BOTH work just fine by using relevant version of Oracle.DataAccess.dll.
    If version is incorrect - for example admin install x64 Oracle client and x86 application - I will have ecxactly the same result as you have.

    Oracle.DataAccess.dll didn't came with my applications and I have nothing to do with it - standard installation by installer from Oracle done by admin.


    Sincerely, Highly skilled coding monkey.

    Thursday, October 10, 2019 2:06 PM
  • Hello,

    Is your problem solved? If so, please mark the useful replies as answers, so that it will help other members to find solution quickly if they faces similar issue. If you have anything else about this issue, please feel free to contact us.

    Best Regards,

    Suarez Zhou

    Monday, October 14, 2019 8:37 AM
  • Hi,

    Still my problem is not resolved.  Is there any option to use multiple platform toolset, for eg:- v60 and v120 in single project.  I'm using Visual Studio 2015.


    MIB


    • Edited by MIB BALA Friday, October 18, 2019 6:33 AM
    Friday, October 18, 2019 6:27 AM
  • Hello,

    read this:

    https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2019

    https://siomsystems.com/mixing-visual-studio-versions/

    The toolset v60 comes from Visual C++ 6, v140 comes from VS 2015. According to the articles you should not mix the versions.

    I found this article too:

    https://docs.microsoft.com/en-us/cpp/porting/overview-of-potential-upgrade-issues-visual-cpp?view=vs-2019

    As far as I understand, mixing libraries is not supported. But you can try to link with legacy_stdio_definitions.lib.

    Nevertheless I think, a dll from Visual C++ 6 is far too old. I didn't find any redistributable packages for VC++ 6 to download. You should rebuild the dll.

    Regards, Guido

    Edit: sorry, you said v90, not v60. v90 Comes from VS 2008. You could try to install the redistributable on the other machine: https://www.microsoft.com/en-us/download/details.aspx?id=29
    • Edited by Guido Franzke Friday, October 18, 2019 7:17 AM not v60, it was v90
    Friday, October 18, 2019 7:14 AM
  • Thanks Guido Franzke,

    I have gone through the shared link and listed my understanding below.  Please guide me whether my understanding is correct and add if it is wrong or missing something.

    01) CRT instance will be created based on the toolset version.  For eg: If we create two dynamic linking library using same visual studio version, but with different toolset version.  Two CRT instance will be created and we should be careful while managing memory.

    02) We should avoid /GL (Whole program optimization option) while using different toolset version

    03) Should install the latest redistributable that supports the highest toolset version, we are using.


    MIB

    Friday, October 18, 2019 11:16 AM
  • Hello,

    If your issue is solved, please "Mark as answer" or "Vote as helpful" post to the appropriate answer , so that it will help other members to find solution quickly if they faces similar issue.

    Best Regards,

    Suarez Zhou


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, November 12, 2019 9:03 AM