I have created a WPF Windows Application project based on the existing standards in the solution. The project properties had Platform Target as Any CPU and says Prefer 32-bit. Mine is a 64-bit machine and the application wasn't launching, it took me while to figure out and turned off Prefer 32-bit to launch it.
My question is what is happening when I say Prefer 32-bit? I expect it to launch it as a 32 bit application on a 64-bit machine. But in my case it does not run, it simply terminates. Why?
Edit:
The problem was when I say Prefer 32-bit or x86 it builds the application in 32-bit mode. Any CPU makes it a 64-bit build. The application launches only in 64-bit mode and when launched with 32-bit mode it terminates without any exception.
After trial and error found out that problem is with the length of the AssemblyName. It was 56 character long after I reduced it to say 36 character it worked fine. Could not get information on whats the permissible limit for 32-bit assembly name and 64-bit assembly name. But 64 bit allows bigger names which has caused the confusion.
Related
I have an application that we're trying to migrate to 64bit from 32bit. It's .NET, compiled using the x64 flags. However, we have a large number of DLLs written in FORTRAN 90 compiled for 32bit. The functions in the FORTRAN DLLs are fairly simple: you put data in, you pull data out; no state of any sort. We also don't spend a lot of time there, a total of maybe 3%, but the calculation logic it performs is invaluable.
Can I somehow call the 32bit DLLs from 64bit code? MSDN suggests that I can't, period. I've done some simple hacking and verified this. Everything throws an invalid entry point exception. The only possible solution i've found so far is to create COM+ wrappers for all of the 32bit DLL functions and invoke COM from the 64bit process. This seems like quite a headache. We can also run the process in WoW emulation, but then the memory ceiling wouldn't be increased, capping at around 1.6gb.
Is there any other way to call the 32bit DLLs from a 64bit CLR process?
You'll need to have the 32-bit dll loaded into a separate 32-bit process, and have your 64 bit process communicate with it via interprocess communication. I don't think there is any way a 32-bit dll can be loaded into a 64 bit process otherwise.
There is a pretty good article here:
Accessing 32-bit DLLs from 64-bit code
You need to write your executable processes as 32-bit processes (versus Any CPU or x64) so that they'll be loaded with WoW32 for Vista. This will load them in the 32-bit emulation mode and you won't have the entry point problem. You can leave you libraries in AnyCPU mode, but your executables have to be compiled as x86.
John's answer is correct if you don't want to recompile your existing dlls; however that might be an option for you as well.
Our team is currently migrating our x86 FORTRAN code to x64 to increase the memory ceiling.
Why is my application, which I compiled with AnyCPU, running as a 32-bit process on my 64-bit machine, and therefore unable to interact with Notepad, which is running as a 64-bit process?
I have the following code which will not run on x64 Operating System since notepad.exe is x64 and a x86 application cannot get the modules information of a x64 process:
prc.Modules[0].FileName
.Net Exception throws on my code:
System.ComponentModel.Win32Exception (0x80004005): A 32 bit processes
cannot access modules of a 64 bit process.
According to many answers and articles on this forum, MSDN, ..., I know that I need to use AnyCPU instead because of the fact that using x64 has no specific benefit for me. Even when Compile on AnyCPU configuration, my error persists, furthermore, in Task Manager I see a (32-bit) at the end of my process name.
(Actually I tested the code with checking performance and the x64 code ran ~40 ms faster. never mind I do not want my code run 40 ms faster :D )
I do not know that is wrong.
VS 2011 Beta (x64)
Windows 8 Consumer Preview (x64)
Sincerely yours,
Peyman Mortazavi
Though the questioner has accepted the answer, I feel like the answer is incomplete since the questioner has mentioned that he is using Visual Studio 2011 and hence assuming the target .Net Framework would be 4.5 there are few caveats with respect to what "AnyCPU" means.
Please refer to both these links, to get a better understanding of how the meaning of "AnyCPU" has changed over time.
http://blogs.microsoft.co.il/sasha/2012/04/04/what-anycpu-really-means-as-of-net-45-and-visual-studio-11/
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/platform-compiler-option
From these links, you can arrive at the answer to the question of why your application is running as 32 bit process
On a 64-bit Windows operating system:
Executables compiled with /platform:anycpu32bitpreferred execute on
the 32-bit CLR.
Here is your culprit.
Go into the project Properties. On the left side, select Build.
Take a look at the "Platform target:" setting for the current active platform. Change it to x64.
(I suspect your "Platform target:" will be explicitly x86 for "Any CPU")
I have a .NET component written in C# that needs to register some registry values under the HKLM hive. I'm expecting this component to be installed on both x86 (32-bit) and x64 (64-bit) boxes running the appropriate flavour of Windows. On 64-bit systems, I want to make sure the component can be used by both 32- and 64-bit hosting processes. I'm stuck with using Visual Studio's deployment projects for the time being.
What I want is for my installer, when run on 64-bit systems, to put its registry entries under HKLM/Software/Blablah, so that when running in a 64-bit process, my component can find its global configuration settings. However, if my component is hosted by a 32-bit process running on the same machine, then it will read from what it thinks is the same key, but which Wow64 will translate to HKLM/Software/Wow6432Node/Blablah.
Is it OK to author my 64-bit installer so that:
it is marked as a x64 installer
it writes the entries under HKLM/Software/Blablah for the benefit of 64-bit processes
it writes exact copies of those entries under
HKLM/Software/Wow6432Node/Blablah for the benefit of 32-bit processes on the same machine.
I'm guessing that because I've marked the installer as x64, I will be forced to author another separate installer specifically for 32-bit systems, which only writes to HKLM/Software/Blablah.
The normal practise is to have both 32 bit and 64 bit install packages. On the 32 bit machine you just run the 32 bit package, on the 64 bit machine you run both.
Trying to handle all the registry and file redirection yourself is a nightmare and it's much better to install a 32 bit package on a 64 bit machine and let the system do the redirection for you. You've got to produce the 32 bit package anyway for 32 bit machines, so it's no extra work.
I have a Any CPU application installed to Program Files (x86). On one Windows 7 x64 machine, it runs as x64 as expected while on another Windows 7 x64 machine, it runs as x86!
How can this be? I expected it to run as x64 on both machines. What might be the reason and what can I do to always make it run as x64?
Does it matter where I am running it from - Program Files (x86) in my case?
It's likely that you linked some assemblies that are not Any CPU, but include native code (or are compiled as x86), which cause the entire process to fall back to x86.
To understand how your assemblies are compiled, a related Stack Overflow question that might help is How to determine if a .NET assembly was built for x86 or x64?*.
Note: the location of the executable on the file system does not matter at all.
We have a Windows Service app written in C# targeted for AnyCPU. It runs on a Win2003 (32bit) server. Recently it started to run out of memory.
What is involved in redeploying this service to a Win2003 (64bit) box. Do I need to recompile it and will the App get more memory if I do not recompile it?
Nothing special if the exe is set for AnyCPU- the 64-bit CLR will load by default on a 64-bit machine. You just have to make sure you're REALLY AnyCPU ready (no unsafe OR safe 32-bit pointer math assumptions, etc). If you're running all managed code with no PInvokes, you should be in good shape.