As I understand the .Net framework there shouldn't be any issues for any code compiled in MSIL runing on a 64Bit system. So why does this section of the forum exist
In addition although C# (and other .NET languages) can be configure to create "agnostic" assemblies, this is not the only option.
One may if they want, build assemblies specifically for certain processor sizes if the wish to.
Also any C code one builds is of necessity, CPU specific and as some other posters have indicated, interfacing C# with any unmanaged C (or C++) libraries requires 64-bit builds of those libraries (if the invoking process is indeed 64-bit).
The reason this will break is because the native code that you have P/Invoked to in Som32BitCode.dll only exists in a 32-bit form (maybe you wrote it in assembly or C++ and only compiled it for 32-bits). So, when you bring this app to a 64-bit platform you will get a BadImageFormatException when the 64-bit managed process tries to load Some32BitCode.dll and can't.
The fix in this case is to make sure to compile WillBreak.cs with the /platform:x86 swtich.
Other code than can fail if executed on a different platform, is code that assumes the IntPtr type is a particular size.
It is 4 bytes on 32-bit Windows but 8 bytes on 64-bit Windows.
I imagine that this could also be an issue for serialization
If I serialize an object that contains (for whatever reason) some IntPtr fields from a 64-bit app and later recreate that object but this time from a 32-bit app, I suspect that I will get a problem.
Why does the 64Bit section exsist?
publicgk
One may if they want, build assemblies specifically for certain processor sizes if the wish to.
Also any C code one builds is of necessity, CPU specific and as some other posters have indicated, interfacing C# with any unmanaged C (or C++) libraries requires 64-bit builds of those libraries (if the invoking process is indeed 64-bit).
Jerry Boggess
Here is a trivial example of a program that can be compiled MSIL which would break on 64-bit machines:
WillBreak.cs
class WillBreak
{
[DllImport("Some32BitCode.dll")]
public static extern int Add(int a, int b);
public static void Main()
{
System.Console.WriteLine("1 + 2=" + WillBreak.Add(1, 2));
}
}
The reason this will break is because the native code that you have P/Invoked to in Som32BitCode.dll only exists in a 32-bit form (maybe you wrote it in assembly or C++ and only compiled it for 32-bits). So, when you bring this app to a 64-bit platform you will get a BadImageFormatException when the 64-bit managed process tries to load Some32BitCode.dll and can't.
The fix in this case is to make sure to compile WillBreak.cs with the /platform:x86 swtich.
-josh
RX7
Jeff Wilcox - MSFT
It is 4 bytes on 32-bit Windows but 8 bytes on 64-bit Windows.
I imagine that this could also be an issue for serialization
If I serialize an object that contains (for whatever reason) some IntPtr fields from a 64-bit app and later recreate that object but this time from a 32-bit app, I suspect that I will get a problem.
Anyone, done this
H
Demian Schnaidman
Check out the latest blog entry from Josh:
http://blogs.msdn.com/joshwil/
lgbjr