locked
Changing references for 64-bit and 32-bit builds. RRS feed

  • Question

  • We have two managed DLL's written in C++/CLI that have unmanaged code in them. They were written as managed wrappers to unmanaged code. We were able to build Win32 and x64 versions of both DLL's. Although, we need to be able to change the references in our project to point to the Win32 or x64 versions of the DLL's depending on the project build (for x86 or x64.)

    Me and another developer have scoured Google and MSDN with no results. The best solution that we have so far is to modify the project on the pre-build event via macros but this is pretty hacky and doesn't play well with the IDE. http://stackoverflow.com/questions/145803/targeting-both-32bit-and-64bit-with-visual-studio-in-same-solution-project

    I don't know if we are asking the wrong question but I am dumbfounded how hard it has been to find information on doing something like this. We ultimately need to cut two versions of our program (32/64-bit) and not AnyCPU since there are underlying dependent DLL's that are unmanaged.
    Tuesday, April 21, 2009 6:31 PM

Answers

  • I knew it had to be in our approach. This works great, thanks.

    For other users out there with a similar issue:
    • Keep the 32-bit versions of the wrapper DLL's in source control so the VS IDE can step through code (not able to in 64-bit.)
    • Set all of your builds to AnyCPU so the managed objects can use 32 or 64-bit DLL's at runtime.
    • When deploying the application (eg. installers), drop in the DLL for that build type (32 or 64.)

    For example, we have a License.dll both in 32 and 64 bit format (2 files.) In Visual Studio, we have the 32-bit version listed in the project references tab and under source control. When it comes time to create the installer, we then drop in either the 32 or 64-bit version of the License.dll, can it and ship.
    • Marked as answer by unreal128 Tuesday, April 21, 2009 10:03 PM
    Tuesday, April 21, 2009 9:07 PM
  • Yes, no wonder you had trouble.  Because that's not what you do.  An assembly reference is only needed for the metadata, the declaration of the classes in the assembly.  And the declarations of managed classes do not depend on the bitness of the assembly.  It matters a great deal at runtime of course, you'll need to properly deploy them.

    Note that it works the same way for the .NET assemblies.  You compile your code with the 32-bit reference assemblies present in c:\windows\microsoft.net\framework, even if the final assembly can only run on 64-bit.
    Hans Passant.
    • Marked as answer by unreal128 Tuesday, April 21, 2009 8:56 PM
    Tuesday, April 21, 2009 6:46 PM
    Moderator

All replies

  • Yes, no wonder you had trouble.  Because that's not what you do.  An assembly reference is only needed for the metadata, the declaration of the classes in the assembly.  And the declarations of managed classes do not depend on the bitness of the assembly.  It matters a great deal at runtime of course, you'll need to properly deploy them.

    Note that it works the same way for the .NET assemblies.  You compile your code with the 32-bit reference assemblies present in c:\windows\microsoft.net\framework, even if the final assembly can only run on 64-bit.
    Hans Passant.
    • Marked as answer by unreal128 Tuesday, April 21, 2009 8:56 PM
    Tuesday, April 21, 2009 6:46 PM
    Moderator
  • I knew it had to be in our approach. This works great, thanks.

    For other users out there with a similar issue:
    • Keep the 32-bit versions of the wrapper DLL's in source control so the VS IDE can step through code (not able to in 64-bit.)
    • Set all of your builds to AnyCPU so the managed objects can use 32 or 64-bit DLL's at runtime.
    • When deploying the application (eg. installers), drop in the DLL for that build type (32 or 64.)

    For example, we have a License.dll both in 32 and 64 bit format (2 files.) In Visual Studio, we have the 32-bit version listed in the project references tab and under source control. When it comes time to create the installer, we then drop in either the 32 or 64-bit version of the License.dll, can it and ship.
    • Marked as answer by unreal128 Tuesday, April 21, 2009 10:03 PM
    Tuesday, April 21, 2009 9:07 PM
  • hi,

    Even I have a project which contains c++ and c# projects (which contains an XLA addin). So i need to generate installers for 32 bit and 64 bit. some scenarios are not working for me:

     

    1) a 32 bit installer (c++ in 'win32' mode and c# project in 'Any CPU' mode) if installs in 64 bit machine and if i open excel Then I get the following error:
    Run-time error '-2147024703 (800700c1)'
    Automation error
    %1 is not a valid Win32 application.


    And if i compile it as  c++ in x86 mode and c# in any cpu mode and installs in 64 bit machine it works fine.

    • is the above scenario is by design/expected?
    • or do i need to change any setting/ perform any action to work 32 bit installer in 64 bit macine?

    please help me in regarding this. Thanks in advance

     

     


    Knowledge is often mistaken for intelligence. This is like mistaking a cup of milk for a cow.
    Thursday, February 10, 2011 1:05 PM