none
64 bit applications - how to ensure that all the code is 64 bit ?? RRS feed

  • Question

  • I have a VS.NET application which includes web components and standalone console/forms applications, and windows services, about 28 projects in the entire solution

    We really want it to build for 32 bit and 64 bit platforms, and we want the 32 bit platform to run on 64 bit within the WOW framework.

    We want to force the 64 bit version to be 100% 64 bit. We can't target x64 as a processor due to that error about mscorlib targeting a different cpu. So 64 bit has to target "any cpu"

    How can I force the compiler to produce error messages if anything is compiling 32 bit, like if there's an api call thats forcing the whole DLL to be 32 bit, instead of it compiling, I want the compiler to raise an error message??

    Otherwise whats happening is half our software is looking for reg settings within wow and the other half outside of wow, which is pretty stupid. And iis is coming up with xxx is not a valid win32 application. So 100% pure 64 bit code is what I'm looking for.. and if there;s any apis etc which can't be 64 bit we'll rewrite them so they can be.

    thanks


    Saturday, April 18, 2009 5:09 PM

Answers

  • 1. Are all the code in your solution written in managed language (VB/C#)?
    [All vb.net 2005 and .NET 2.0, one small MSVC6++ project which compiles to a 32 bit DLL and called via "declare auto function", otherwise 23 vb.net 2005 projects and]
    Okay, the VC++ 6 project needs to be built as x64. Otherwise when your VB.NET app running as x64, an x86 DLL cannot be loaded into the process.
    I think there are two options:

    1. Install Windows Platform SDK to have x64 compiler for your VC++ 6 project.
    2. Migrate the VC++ 6 project to VC++ 2005, and compile as x64 (on x86 machines, this option is not installed by default).

    2. Does your code call any unmanaged components directly or indirectly via P/Invoke?
    [There are some "Declare Auto Function" winapi calls within the product, but they can all be worked around. I dont really know much about p/invoke just yet]
    If these API function declarations are calls to the system DLLs (like kernel32, user32, gdi32), they usually have corresponding 64bit version on x64 OS. You don't have to make changes to the code. If some are calls to your own DLLs, like the VC++ 6 project, you'll have to compile your DLLs as x64 and ship the correct version.
    3. Is your development platform a 64bit OS?
    [its 32 at the moment, but I have 64 bit OS machines here I can use if needed. I thought I might still get the same issues of the final code going into wow out of my control]


    Reading into your question 3, can I ask, would a 64 bit OS platform allow me to target x64, instead of getting the "mscorlib targets a different cpu" error message on a 32 bit OS build platform ?? I must admit I would prefer to not have to dedicate 2 machines to run builds !! 
    Yes, you're getting this message because on an x86 machine the compiler cannot find the x64 version of mscorlib. Setting target platform as AnyCPU will be easier to maintain the output (one copy only) but setting target platform as x64 (to force and make sure it runs as x64) will be easier for discovering problems during dev & testing.

    The only external references other than that 32 bit c++ dll are to telerix rad chart and datadynamics activereports, I'm sure theres 64 bit versions of these.
    Yes, you definitely need x64 versions of them.

    Regards,

    Jie
    This posting is provided "AS IS" with no warranties, and confers no rights.

    The CodeFx Project
    My Blog (CHS)
    Tuesday, April 21, 2009 3:58 AM
    Moderator

All replies

  • Hello PAULL,

    Before we go into many details, I'd like to know more about your solution.

    1. Are all the code in your solution written in managed language (VB/C#)?
    2. Does your code call any unmanaged components directly or indirectly via P/Invoke?
    3. Is your development platform a 64bit OS?

    Now let me answer your questions:

    How can I force the compiler to produce error messages if anything is compiling 32 bit, like if there's an api call thats forcing the whole DLL to be 32 bit, instead of it compiling, I want the compiler to raise an error message??

    For .NET applications, the source code is being compiled MSIL (NOT machine code), which is always platform agnostic. Only at runtime the MSIL being compiled into CPU specific machine code. And the compiler won't know if you're P/Invoke some native component which is x86 or x64 only. Setting the Target Platform only causes a difference in the PE header. When setting the target platform to x86, the PE flag in the PE header will be PE32 and the 32Bit flag is set to 1; when setting the target platform to AnyCPU, the PE flag = PE32 and 32Bit = 0; when setting the target platform to x64, the PE flag = PE32+ and 32Bit = 0.

    So generally speaking, before porting the code to 64bit platform, we'll need to go through all the references in the projects and make sure those references to native components do have an x64 bit version. If any of the native components have x86 version only, you can't call them directly from a x64 process, so your app need to be run as x86 too.

    And to review the code for incorrect use of data type which could go terribly wrong when running as 64bit. For example, use Integer for pointers or handles instead of IntPtr in P/Invoke is a bad practice.

    The complier can't know these.

    Here are some general references for 64bit .NET programming:
    http://blogs.msdn.com/gauravseth/archive/2006/03/07/545104.aspx
    http://msdn.microsoft.com/en-us/netframework/aa496402.aspx

    Since I don't know much details about your dev environment, I can only give general opinions. If you have more specific follow up questions, please feel free to let me know.

    Thanks,

    Jie
    This posting is provided "AS IS" with no warranties, and confers no rights.

    The CodeFx Project
    My Blog (CHS)
    Monday, April 20, 2009 11:24 AM
    Moderator
  • This is a great start.

    1. Are all the code in your solution written in managed language (VB/C#)?
    [All vb.net 2005 and .NET 2.0, one small MSVC6++ project which compiles to a 32 bit DLL and called via "declare auto function", otherwise 23 vb.net 2005 projects and]

    2. Does your code call any unmanaged components directly or indirectly via P/Invoke?
    [There are some "Declare Auto Function" winapi calls within the product, but they can all be worked around. I dont really know much about p/invoke just yet]

    3. Is your development platform a 64bit OS?
    [its 32 at the moment, but I have 64 bit OS machines here I can use if needed. I thought I might still get the same issues of the final code going into wow out of my control]


    Reading into your question 3, can I ask, would a 64 bit OS platform allow me to target x64, instead of getting the "mscorlib targets a different cpu" error message on a 32 bit OS build platform ?? I must admit I would prefer to not have to dedicate 2 machines to run builds !! 

    The only external references other than that 32 bit c++ dll are to telerix rad chart and datadynamics activereports, I'm sure theres 64 bit versions of these.

    thanks
    Monday, April 20, 2009 12:27 PM
  • 1. Are all the code in your solution written in managed language (VB/C#)?
    [All vb.net 2005 and .NET 2.0, one small MSVC6++ project which compiles to a 32 bit DLL and called via "declare auto function", otherwise 23 vb.net 2005 projects and]
    Okay, the VC++ 6 project needs to be built as x64. Otherwise when your VB.NET app running as x64, an x86 DLL cannot be loaded into the process.
    I think there are two options:

    1. Install Windows Platform SDK to have x64 compiler for your VC++ 6 project.
    2. Migrate the VC++ 6 project to VC++ 2005, and compile as x64 (on x86 machines, this option is not installed by default).

    2. Does your code call any unmanaged components directly or indirectly via P/Invoke?
    [There are some "Declare Auto Function" winapi calls within the product, but they can all be worked around. I dont really know much about p/invoke just yet]
    If these API function declarations are calls to the system DLLs (like kernel32, user32, gdi32), they usually have corresponding 64bit version on x64 OS. You don't have to make changes to the code. If some are calls to your own DLLs, like the VC++ 6 project, you'll have to compile your DLLs as x64 and ship the correct version.
    3. Is your development platform a 64bit OS?
    [its 32 at the moment, but I have 64 bit OS machines here I can use if needed. I thought I might still get the same issues of the final code going into wow out of my control]


    Reading into your question 3, can I ask, would a 64 bit OS platform allow me to target x64, instead of getting the "mscorlib targets a different cpu" error message on a 32 bit OS build platform ?? I must admit I would prefer to not have to dedicate 2 machines to run builds !! 
    Yes, you're getting this message because on an x86 machine the compiler cannot find the x64 version of mscorlib. Setting target platform as AnyCPU will be easier to maintain the output (one copy only) but setting target platform as x64 (to force and make sure it runs as x64) will be easier for discovering problems during dev & testing.

    The only external references other than that 32 bit c++ dll are to telerix rad chart and datadynamics activereports, I'm sure theres 64 bit versions of these.
    Yes, you definitely need x64 versions of them.

    Regards,

    Jie
    This posting is provided "AS IS" with no warranties, and confers no rights.

    The CodeFx Project
    My Blog (CHS)
    Tuesday, April 21, 2009 3:58 AM
    Moderator
  • Thanks Jie,

    It will take me a while to work through this so I'll leave this thread open, and maybe update it when I've got it all working as a kind of howto posting..

    FYI we've set TargetPlatform all along to x64, yet still the binarys will look in WOW for a reg setting (i.e. they are running as 32 bit) rather than raising an error message, so TargetPlatform=x64 doesnt seem to "force it and make sure it runs as x64"  (this is vs2005 compiler)

    thanks again.. will post an update asap

    Tuesday, April 21, 2009 2:43 PM