Question 174029 in Visual Studio Code Question posted in
View the official documentation.

Visual Studio Code – Why does VB.Net detect an x86 OS architecture while C# detects x64?

Same code executed executed on same computer gives different output:

VB code

Private Shared Function getOSPlatForm() As String
    Dim OsPlatForm As String = Nothing
    If IntPtr.Size * 8 = 32 Then
        OsPlatForm = "X86" 'win 32bit
    Else
        OsPlatForm = "X64" 'win 64bit
    End If
    Return OsPlatForm
End Function

This outputs x86.

C# code

private static string getOSPlatForm()
{
    string OsPlatForm = null;
    if (IntPtr.Size * 8 == 32)
    {
        OsPlatForm = "X86";
        //win 32bit
    }
    else
    {
        OsPlatForm = "X64";
        //win 64bit
    }
    return OsPlatForm;
}

This outputs x64.

Both projects have the same running configuration to run on AnyCPU and I’m using visual studio 2019.

running configuration

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    OK after trying with winapi and giving same wierd result, I found solution thanks to you guys. On VB.net the next line returns the right Arquitecture Environment.Is64BitOperatingSystem

    Because

     <DllImport("kernel32.dll")>
        Shared Sub GetSystemInfo(ByRef lpSystemInfo As SYSTEM_INFO)
'does not return x64 system

  2. 0

    Your project settings must be different.

    The c# or vb.net code in both cases will and should produce the same results.

    The ONLY reason for a difference is:

    You defaulting and running vs2022, and using "ANY CPU".

    This will result in a x64 bit application.

    With vs2019, using ANY CPU will result in a x32 bit application.

    Reason:

    vs2022 is the FIRST version of visual studio that is x64 bits (yes, all these years vs has been a x32 bit product).

    So, what that means is that you REALLY now need to pay close attention to what bit size settings you use for a given project.

    That is this setting:

    enter image description here

    If you set both the vb.net and c# project to x86, then your code will produce the same results. (x32 bits)

    And if you set both the vb.net project and c# project to x64, then your code in both cases will produce the same results.

    And when using ANY cpu?

    Well, then what bit size you get DEPENDS on how and who and what launches the project.

    If you launch a x32 bit version of the command line, then ANY cpu will result in x32 bits.

    But, if you launch a x64 bit version of the command line, launch the .exe program, then you get a x64 bit running version.

    So, WHICH kind of in-process routine – including that of visual studio launching the program (even using f5)?

    Well, if you use vs2022 (x64), or previous versions (x32), then you get different result WHEN using any CPU.

    So, in near all cases, if you don’t care, then I do suggest using ANY CPU, since I have a number of class projects I share between some desktop software (x32), and some web based software (x64). However, I actually include the several of these class projects in both the x32 and the x64 bit based projects.

    And in fact I FORCE the build to the given required bit size I need/want (in the case of web based – it has to be x64 bits in my case. And this is due to web servers running as x64 bits these days, and more so since I am using some un-managed .dll’s (non .net) in that project from .net.

    Last but not least?

    If you want to determine the bit size, you can indeed use the IntPr.Size, but a more preferred and typical means is built into the .net frame work.

    Thus, this: (.net 4.0 or later)

            textBox1.Text = 
            System.Environment.Is64BitProcess ? "X64 but program" : "x32 bit program";

    And you have a few other nice ones:

    System.Environment.Is64BitOperatingSystem;

    Now, these days, MOST os are x64 bits. But, if we go back about 10 years ago, we would still see quite a few desktops – even from OEM’s that has x32 bit versions of windows installed.

    However, these days, you can expect your OS to near always be x64 bits.

    About the only real reason to "force" a project to run as x32 bits is when you dealing with un-managed code.

    Some good examples:

    Accounting packages: Sage 50, Sage300, QuickBooks and more?

    They are currently all x32 bit based products. So, if you using say their SDK’s to interface to such accounting packages, then you MUST force your .net project to run as x32 bits (x86 settings).

    Same goes for most office automation. Word, Excel, ms-access and even the ms-access ODBC or oleDB drivers? Again, you MUST match your .net project to the bit size of office you are running.

    Turns out JUST in the last year, office is now starting to default to x64 bits, and thus you now have to set your .net projects that interface directly to office to now use x64 bits, where as even to the relative recent past, all such projects in general had to run as x32 bits.

    So, in summary:

    Both your .net and vb.net projects SHOULD produce the same results. The ONLY reason for different results is you failing to FORCE the project settings to a given bit size, and are probably using ANY CPU in one of the projects.

    Short version: force the project settings if you desire a particular bit size for your .net code.

    both your vb.net and c# posted code will and should produce the same results – it is a matter of setting/choosing the SAME project settings for the CPU in both projects.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search