I create application in visual studio 2010.
I tested on server 2003 r2 x64 and the program does not start.
trying to compile x64 and I crash exception
Error while Trying to run Project:
Debugger cannot start: The assembly to
be debugged was built with platform
incompatible with the current system
If your application references 32-bit .dll-files it can't run as 64-bit. Either .Net assemblies compiled to x86-target (which is default now), or P/Invoke on native Windows .dll-files, will prevent you from running your 64-bit app.
The Windows installation you are running this on also needs to be 64-bit in order for it to handle 64-bit debugging. (Note: Compiling to 64-bit will work fine!)
Set target CPU type to x86 in project properties (under Build) to make it work. If you don't reference any external 32-bit .dll's you can set it to "any" to let .Net decide. It will then run 64-bit mode on 64-bit operating systems and 32-bit mode on 32-bit operating systems.
I'm not sure about VS2010, but for VS2005 I build with "Mixed Platforms" set for "Active solution platform."
Related
It is unclear to me how the compiler will automatically know to compile for 64-bit when it needs to. How does it know when it can confidently target 32-bit?
I am mainly curious about how the compiler knows which architecture to target when compiling. Does it analyze the code and make a decision based on what it finds?
Microsoft has a blog entry What AnyCPU Really Means As Of .NET 4.5 and Visual Studio 11:
In .NET 4.5 and Visual Studio 11 the cheese has been moved. The
default for most .NET projects is again AnyCPU, but there is more than
one meaning to AnyCPU now. There is an additional sub-type of AnyCPU,
“Any CPU 32-bit preferred”, which is the new default (overall, there
are now five options for the /platform C# compiler switch: x86,
Itanium, x64, anycpu, and anycpu32bitpreferred). When using the "Prefer 32-Bit"
flavor of AnyCPU, the semantics are as follows:
If the process runs on a 32-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
If the process runs on a 64-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
If the process runs on an ARM Windows system, it runs as a 32-bit process. IL is compiled to ARM machine code.
The difference, then, between “Any CPU 32-bit preferred” and “x86” is
only this: a .NET application compiled to x86 will fail to run on an
ARM Windows system, but an “Any CPU 32-bit preferred” application will
run successfully.
Here's a simple answer:
Note: AnyCPU-32bitPreferred is only available in .Net version 4.5 and higher.
When I had 32 bit preferred checked, when run on our server, it was trying to use the 32 bit db driver instead of 64 bit that we had installed, so it wasn't connecting to the db when we ran it, so queries were failing because of failure to connect.
The reason is: in case you don't want to use more memory with 64 bit applicatios. Which means, if your application is AnyCPU, you want to run as 32 bit.
To add more, the setting in Visual Studio targets the particular CLR:
Visual Studio installs the 32-bit version of the CLR on an x86 computer, and both the 32-bit version and the appropriate 64-bit version of the CLR on a 64-bit Windows computer. (Because Visual Studio is a 32-bit application, when it is installed on a 64-bit system, it runs under WOW64.)
Please refer to the article 64-bit Applications (MSDN).
I'm trying to hook a simple process using EasyHook. I'm programming/debugging in a x64 environment and compiling my DLL with AnyCpu config on Visual Studio C#.
The problem is that when trying to use this DLL (in another project, same Solution, compiling with AnyCpu too) in the inject library function:
RemoteHooking.Inject(TargetPID, "DivisionInject.dll", "DivisionInject.dll", ChannelName);
(2nd parameter is for 32-bit system. 3rd is for 64 bit.)
I don't know why this line is throwing an exception:
System.ArgumentException: the given 64-Bit library does not exist!
I thought that AnyCpu used to create my DLL, i could use the same file (DLL) in 32bits system and on 64 bits too. Is this wrong?
Thanks.
The AnyCpu setting basically means that the determination of how the process or library will be loaded or executed will be based at/on the point of execution/load. A library compiled as AnyCpu will be loadable by both a 32bit and a 64bit calling process. An executable compiled as AnyCpu will run a 64bit process on a 64bit machine and 32bit on a 32bit machine. See this thread for a discussion on the concept of the AnyCpu target.
If your caller is compiled as 64bit and set to AnyCpu, it will be attempting to load the 64bit library.
While it is now less common, it is possible to install Windows 32-bit on a 64-bit machine. In this case, only exe's built for 32-bit/AnyCpu will run. The converse is obvious. 32-bit machines can only run Windows 32-bit.
Thus the O/S bitness is the determining factor, not the hardware.
Windows 32-bit on a 64-bit machine was more common in enterprise shops, that didn't want to support both O/S's or 32-bit legacy applications running on Windows-64.
As title suggests I am compiling C# app using VS 2012 on a 64-bit machine. I would like the program being built to run on a 32-bit machine.
Right now the only help I found online was for:
Menu>Build>Configuration>
Active Solution Platform defaulted to Any CPU, and I tried that but didn't work on 32-bit machine (unless I did something wrong)
Tried Add a new one to the Debug configuration for platform x86 with build checked
Compiled and ran the app on 32-bit machine getting error A.exe is not a valid Win32 application.
My above was similar to what was done here: Link to Stack Overflow Similar Question
UPDATE 1:
The target OS is WinXP SP3 but we dont believe it has .NET 4.5 on it. I will be testing to see if compiling earlier ver of the app in .NET 4.0 will solve the problem and fix the problem. The problem may not be what the error message is displaying.
Setting your project to target AnyCPU should allow it to run on a 32bit machine, provided you aren't using a library which loads 64bit native code. If you have any dependencies, you'll need to make sure to use AnyCPU or 32-bit versions of those dependencies, as well. Also, make sure you have the proper .NET Framework installed on the 32bit machine (.NET 4.5 by default, if you're using VS 2012 with a new project).
Note that the default in VS 2012 for new projects is AnyCPU, with the Prefer 32 Bit option checked. This will cause it to always run as a 32bit application, even on your 64bit OS.
Note that, since your friend is running XP sp3, you can't use .NET 4.5. .NET 4.5 is not supported on Windows XP. You will need to change your application to target .NET 4.0, which will then work on the XP machine (if he installs the 4.0 framework).
That error is the Win32 error ERROR_BAD_EXE_FORMAT. It's generated by the loader and is what happens when you try to run a 64 bit process on a 32 bit operating system. There are other ways to see that error, but this is by far the most common reason for it to occur on a .exe file.
To compile a 32 bit process you need to target x86 in your project configuration. Another alternative would be to target AnyCPU. That will result in a 32 bit process when executed on a 32 bit OS, and a 64 bit process when executed on a 64 bit OS. It would appear that your build targets x64.
The Platform name (shown on the top of the properties, page "Build") is only a name. The same for "Active Solution Platform" in configuration editor. This is a bit confusing.
You have to make sure that the "Target platform" setting is really set to "AnyCPU" or "x86".
I had same problem. I strugle with it. and the and I found a solution.
The solution is :
Firstly choose platform target "x86". After that build your project as "release mode" not "Debug mode". finally you can run on any platform (32 bit or 64 bit).
If none of the solutions presented above helped you, then try the following:
Open the project properties and click General in the left column.
Change Platform Toolset to the one with Windows XP in it.
For example, in Visual Studio 2015 it will default be set to "Visual Studio 2015 (v140)". To be able to run on Windows XP, you have to change this to "Visual Studio 2015 - Windows XP (v140_xp)".
Now do a full rebuild, and the exe should work on Windows XP.
I'm using Windows 7 and x64 cpu.
Does it mean that I should always compile with "x64" option in Visual Studio? What about "dll", can I use x86 dll from x64 application? Probably there are other concerns?
This article contains a brief overview of each option.
Here's a small quote:
The default setting, Any CPU, means that the assembly will run
natively on the CPU is it currently running on. Meaning, it will run
as 64-bit on a 64-bit machine and 32-bit on a 32-bit machine. If the
assembly is called from a 64-bit application, it will perform as a
64-bit assembly and so on.
If the project is set to x86, this means the project is intended to
run only as a 32-bit process. A 64-bit process will be unable to call
into an assembly set as X86. Reasons to set your project as x86
include dependencies upon native DLLs that are only available in
32-bit or making native calls assuming 32-bit . Applications and
assemblies marked for x86 can still run on 64-bit Windows. However
they run under WOW64. Visual Studio itself runs under this emulation
mode since it is a 32-bit application.
Setting the project to x64 will specify that the assembly must run
under 64-bit Windows. Attempting to run the assembly on 32-bit
Windows or call the assembly from a 32-bit process will result in a
runtime error.
Generally speaking, you should use AnyCpu all the time.
If you have specific reasons to expect compatibility problems with that, then you'll need to choose x86 or x64 as appropriate.
As noted in the comments, dll's built against specific architectures can require you to build your assembly a certain way. This will be something you'll want to do when you need to, not otherwise.
No... the machine you write your code on/compile/build your software (EXE, DLL...) does not have anything to do with the question which target (x86 / x64 / Any).
IF you want the result of the build to run anywhere you use either x86 or AnyCPU. If you want the result to run on x64 only then you use x64.
There are some cases where you must use x86 or x64 - that is when you use some (3rd-party?) component/library/DLL/ActiveX etc. in your project which is 32 Bit only (then x86) or only 64 Bit only (then x64).
AnyCPU is what I generally recommend. You can see this issue discussed in depth at this SO post.
The only concern is that you cannot go backwards - you can't use an x64 assembly from a x86 application. AnyCPU alleviates this potential pitfall.
This question relates to these previous question on SO
Any CPU question 1 and Any CPU Question 2
I have a application which was originally built on Win XP using Visual Studio 2005 (don't laugh!). This app calls into our win32 C++ dll. The C# components which call the C++ dlls were built with the "Any CPU" configuration and have been happily working on Win XP without any issue.
We are now moving to Win 7 and the release version of our app (which was built on Win XP with VC 2005) works fine. However with the roll out of win 7 to our users we have now taken the opputunity to move to VS 2010 and I have built the C# components on win 7 with VC 2010 but now when running this version I get lots "unable to load abc.dll" where abc.dll is our win32 c++ components.
I understand that recompiling the C# assemblies with x86 config will solve the problem but what I don't understand is how the release version c# assemblies built with Win-XP/Visual studio 2005 (Any CPU config) are able to run on Win 7 without any issues? Surely these C# assemblies built with "Any CPU" should JIT to 64 bit code when loaded in Win 7 and cause BadImageFormatException or other errors because they call Win32 C++ dlls.
UPDATE : I have Some more information that have been requested in the comments below.
On my Windows 7 box I right click on my computer and look at the properties. The System information says "System Type : 64 bit operating system" confirming this is a Win64 OS.
Opening up the solution in VC2005 on Windows XP When viewing the configuration manager for the solution I can confirm ALL the C# projects are platform type "Any CPU".
When running the release build (which was done on VC2005/win xp) on 64bit Win 7 machine, I task manager shows the image name as "Test.exe *32", this confirms it is jit'd and loaded into 32bit process.
Under Win7, the process is 64-bit. 64-bit processes cannot have 32-bit DLLs in them, that's a pretty fundamental design limitation of Windows.
And the fact that this managed code EXE calls into a 32-bit DLL is not obvious from the get-go - P/Invoke, as well as COM interop, works via late binding. So the EXE is loaded, the loader does not check the dependencies - for one thing, the dependencies might be conditional - then the DLL loading time comes, wackiness ensues.
So yeah, if you have managed code with known 32-bit dependencies, you better specify a 32-bit CPU at compile time. Or recompile the C++ parts to 64 bits, that's also an option.
I can confirm that you should get BadImageFormatException. Is it possible that the compilation on XP was monkeyed with badly enough that it's not actually building AnyCPU but rather builds x86 labelled as AnyCPU. I can also confirm it's possible to monkey with a project file badly enough that it would do that and the project upgrade component chokes on that.
One possible explanation is that one of your projects in the solution on the 32-bit development system had a binary reference to a 32-bit assembly, which would force it to be loaded as a 32-bit process even on 64-bit systems.