If so are the changes I would need to make to an existing program written in c# vast?
This MSDN page has more information on 64 bit Applications:
All applications built with the 1.0 and 1.1 releases of the .NET Framework are treated as 32-bit applications and are always executed under WOW64 on the 32-bit common language runtime (CLR) on a 64-bit operating system. In addition, 32-bit specific applications built with version 2.0 of the .NET Framework would run under WOW64 on 64-bit platforms.
So you need .NET 2.0 to be able to target 64 bit specifically.
This link might provide some pointers assuming it is Visual studio 2003 you are referring to:
http://www.toymaker.info/Games/html/64_bit.html
Visual Studio 2003 only targets the 32 bit platform, so you would need a newer version to create an application that can run in 64 bit mode.
Normally you don't have to make any code changes at all to make an application compatible with the 64 bit platform. I have done a lot of development and testing on a 32 bit computer and published on a 64 bit web server, and also the opposite.
Related
I created a Library with C# over a year ago under windows 7 32-bit and it works correctly, this library use the "User32.dll" and "Gdi32.dll" libraries.
at first I compiled this library for AnyCPU it work on 32bit but it does not work on win 64bit, I Also compiled it for 64bit CPUs but the same happened again.
my library uses the "RawInput devices" from "User32.dll" and "GetDeviceCaps" from "gdi32.dll".
This article in channel9 says:
Third party DLL's, which are 32 bit in nature, cannot be accessed from 64 bit clients. I have yet to see any workarounds for this that actually work. Apparently .NET DLL's will auto-adjust if compiled with "Any CPU" and called from a 32 bit or 64 bit host client.
And also in this question in MSDN:
A 64bit executable cannot call a 32bit dll and viceversa. Unless you actually need your application to be 64bit, the simplest option is to set it to target x86. This will still allow it to run on both 32 and 64bit versions of Windows.
If for some reason this is inapplicable, a possible solution would be to create a separate 32bit process that would load the 32bit dll, and have your 64bit application communicate with the other process, possibly using IPC (in some trivial case, redirecting the standard input and output can also work, or even just inspecting the return value of the process). In any case, this results in some extra work; I would advise you to review accurately your requirements first.
We have a small application that is based on the .NET 2 Framework (C#) and is compatible with WindowsXP to Windows 8 but only 32bit (because our build machine was always 32bit too).
We are now looking to make some changes and also create a 64 bit version now.
My question is now, should we also upgrade to a newer version of the .NET Framework to be ready for the future or can we just stay with our existing .NET Framework 2.
It should still be compatible to Windows XP and all newer Windows (32 and 64 bit).
You can always upgrade it to version 4 of framework and it will still be compatible with the previous versions of windows.
Apart from that, you should always build the .Net application with "Any CPU". It will generate the intermediate code and later the JIT compiler will compile it to either 32bit or 64bit architecture depending on what machine it is being executed.
You should bother about CPU architecture only if you are referencing any unmanaged dll in your .Net application.
yes, It will still remain compatible to windows XP and all newer version of windows too. With upgrade to framework 4, you must have windows XP sp 3 as framework will not install otherwise.
As far as I know, framework 4.5 can only be installed on windows 7 or higher so upgrading to framework 4.5 might not be the option for you.
Upgrading to .NET 3.5 or 4.0 shouldn't pose a problem, the drawback being that fewer people will have the framework installed, and the benefit being that you get a better CLR and can use some new language features.
If you aren't going to change the application source, you won't take advantage of any new language features, and you are only going to add a new dependency (the newer framework) for the end user. I can't see any point in going from 2.0 to 4.0 in that case.
If you are going to continue developing the application at all, then I highly recommend moving to 3.5 or 4.0 to get the new features in those frameworks, most importantly LINQ.
Do note that the 4.5 Framework isn't compatible with Windows XP so you can't upgrade to 4.5 if you want to keep backwards compatibility with XP. As long as you need to target XP you are stuck with 4.0 or less.
As for output platforms, I recommend compiling like this:
Assemblies with native dependencies: Explicitly compile x86 and x64.
Entry point assemblies (.exe's basically): Explicitly compile for x86 and x64.
All other assemblies: Compile as AnyCPU.
Using explicit platform for executables is a good principle because it is least surprising for the user, and allows users on 64bit systems to run the 32bit application if they want. See this blog post for a longer answer http://blogs.msdn.com/b/rmbyers/archive/2009/06/09/anycpu-exes-are-usually-more-trouble-then-they-re-worth.aspx
I have to deploy a C# application on a 64 bit machine though there is a slight probability that it could also be deployed on a 32 bit machine. Should I build two separate executables targeting x86 and x64 platform or should I go for a single executable built targeting 'AnyCPU' platform (specified in the project property's Build option'. Would there be any performace difference between a C# assembly built targeting 'AnyCPU' is deployed on a 64 bit machine vs the same assembly built targeting specifically 'x64' platform ?
No, there is no difference in performance between AnyCPU application running on a 64-bit Windows and an x64 application running on it. The only thing that flag changes are some flags in the header of the compiled assembly and the CLR uses it only to decide whether to use x86 or x64, nothing else
If you were asking whether there is a difference between x86 application running on a 64-bit Windows and an x64 (or AnyCPU), then the answer would be yes. The differences between the two are:
64-bit obviously uses references that are twice as big as 32-bit, which means larger memory consumption, but it also means you can use more memory
64-bit can use more registers that are available only in the 64-bit mode of CPUs
64-bit JIT is different from 32-bit JIT, it has different set of optimizations: for example 64-bit JIT sometimes uses the tail call optimization even if you don't specifically request it using the tail. instruction (which for example C# never does)
As a side note to the above answer. There can be issues with using P/Invoke or DotNetInterop into x86 DLL's on an x64 OS using AnyCPU. In the case where no 64-bit version of the DLL is available, it may be necessary to compile x86 rather than AnyCPU as the OS will try to load the 64-bit version...and fail.
I am developing application which uses ODP.NET to connect to Oracle DB. I would like to have one version for both 32bit and 64bit machines. The problem is that I couldn't figure out how to build projetc with anycpu target, seems it requires the target to be the same as ODP driver version. So it means that I need to have to versions of the same application one for 32bit and other for 64bit. But the same was not problem while using MS .NET Oracle client (System.Data.OracleClient). Is there a way to have the same behavior using ODP.NET as on MS .NET client?
Just update few years later: Oracle released managed ODP.NET client, so there's no need to bother with x64/x86 in .NET applications any more. You can find more information on Oracle website: http://www.oracle.com/technetwork/topics/dotnet/index-085163.html
The root cause is the ODP.NET's reliance on native OCI DLLs, which of course cannot be "Any CPU".
Theoretically, ODP.NET could detect the "bit-ness" of the current execution in the .NET code and then dynamically load either 32-bit or 64-bit native DLLs accordingly, but that's not how it is currently implemented.
Oracle corporation is currently in the process of implementing a fully managed provider. But until then, we are stuck with having to do separate builds for each "bit-ness".
The default option for any C# project is it will work on both x64 and x86 operating systems.
So it means that I need to have to versions of the same application
one for 32bit and other for 64bit. But the same was not problem while
using MS .NET Oracle client (System.Data.OracleClient).
This is expected....You need to release a x86 version and a x64 version, please take note, x86 application cannot reference a x64 assembly and vice-versa.
The reason the Microsoft reference was different was because its part of the .NET Framework by default.
I cannot download the file where I am at, I do believe that, ODP.NET has a x86 assembly and a x64 assembly.
The correct way is to release a x86 version and a x64 version of your program.
ODP.NET is specifically built for either 32-bit or 64-bit platform. They could have built a single library for AnyCPU which would allow it to be used in a 32-bit or 64-bit process. However, as Branko Dimitrijevic alluded to, the ODP.NET managed dll uses native libraries behind the scenes. Native libraries are platform-specific; thus requiring Oracle to build separate ODP.NET library for each platform. There is no alternative.
IS there a different in WebService programming in 32bit and 64bit ?
under server 2003 (C# programming )
thank's in advance
There is really no difference between a 32 and 64 bit C# Web Service program than there is for any other type of C# program. The .Net framework was designed to be a mostly platform agnostic framework and it only creeps up in certain areas. Namely
PInvoke: Ideally this is written in a platform agnostic manner but it can be done incorrectly to be tied to a specific platform
COM Interop: Native component may be tied to a particular architecture
(to re-state Jared's reply in slightly different terms)
If you use pure .net code, then just compile for "Any CPU" (the default) and it will work in 32-bit and 64-bit environments.
However, if any part of your application (e.g. a C++/COM dll) is 32-bit, then you have to change the compile type to "x86" to force the entire application to run under WOW64 (as a 32-bit application), or you have to rebuild/get the dll in a 64-bit native form. Essentially you cannot mix 32-bit and 64-bit code in your application.