Hello
I want to create a 64bit application in c# and I wan't to use in it a dll created in C++ builder (32bit). But when I try to load the dll the application crashes. When built in 32bit it works. Is there a way to use this dll in a 64bit app?
No this is not possible. A process in Windows is either 32 or 64 bit and it can only load DLL's which match. Any attempt to load a DLL which does not match will fail and produce an error.
If you need to match 32 and 64 bit code you need to use multiple processes. In this case though I would just make the application 32 bit or the DLL 64 bit
Do you want to build a 64-bit application, or you want to build an application that will run in a 64-bit environment? Your application can run perfectly fine in a 64-bit environment even when the target platform is x86.
You cannot load a 32-bit DLL into a 64-bit process on Windows.
I have never tried it myself, but you might be able to create a seperate 32-bit application that can run in a different process and act as a proxy for the DLL. Your application could then run 64-bit and communicate with the DLL with remote procedure calls over WCF.
If performance is a concern, then your best bet would be to rebuild the DLL in 64-bit, if possible.
Related
My application is built as a x64 application. After moving to VS2010 I got some problems which seems to be related to some x64/x86 mismatch in referenced dlls. Now I'm moving to target .NET4, and I get even more similar problems.
My question is: What precautions do I need to take regarding mixing x64 and x86. Can it be done at all? I thought x64 applications should be able to use x86 dlls without problems. No? What about the other way? Can a x86 application reference an x64 dll - as long as it is being run on an x64 platform? What are the pitfalls I need to be aware of?
No, a 64-bit process can only load 64-bit DLLs and a 32-bit process can only load 32-bit DLLs. What you're probably thinking of is that a 64-bit operating system can run 32-bit processes.
The main issue with .NET is that - prior to VS2010 - executable projects defaulted to "AnyCPU" which means it would load in the "native" format of the OS it's running on (so 32-bit for 32-bit versions of Windows and 64-bit for 64-bit versions of Windows). The problem with that is that if you tested your application on 32-bit Windows (say) then it could break if you load 32-bit DLLs and tried to run on 64-bit Windows.
In VS2010, they defaulted all executable projects to be "x86" (that is, 32-bit) by default which (for the most part) mitigates the problem.
You can run x86 apps on a 64 bit OS using WOW32 emulation. Some pitfalls that I have encountered - you can't mix and match 32/64 in the same process. So if you intend to run IIS as 64 all the assemblies need to be 64 otherwise you'll have to run In 32 bit mode. 64 bit helps some apps more than others. Running SQL sever's 64 bit version provides several advantages over the 32 bit version, biggest advantage being that yo can install more than 4 GB of memory on the target server and that SQL will be able to use more than 4 GB of memory. It does not benefit IIS as much because IIS typically can't use more than 3 gb of memory. My advice would be to make sure your SQL server/os/version are 64 if possible. It's not going to make a. Huge dfference if the other servers are 64 but typically it's easier to work with and find 32 bit versions.
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.
I am trying to create a webservice where the functions are performed by a 64 bit DLL. When I try to build this service i get the error "An attempt was made to load a program with an incorrect format."
But when I run a 32 bit DLL it works fine.
I am trying to run in a visual studio 2012 on .net 4 framework in C#
I have tried changing the app pool settings in IIS and changed build platform target to any cpu. Cannot identify where the problem is coming from. Please provide you assistance. Thank you
Right click on the application pool you are using and go to Advanced Settings. Under (General) there is a setting called Enable 32-Bit Applications. If you're running on a 64 bit OS and this is set to true then the app-pool will be a 32bit process, and therefore your 64bit DLL won't load. Set it to false to make your app-pool a 64bit process.
Also, check the dependencies of the DLL you're building as 64bit. It may be using a 32bit dll/assembly. If you've got any [DllImport] attributes in your code then look at the .dlls they refer to and ensure they're 64bit compatible.
If your web service references 64 bit dlls it must be compiled to x64
Try not to mix AnyCPU compilation with 32 or 64 bit DLL (DLL can be compiled as 32bit or 64bit or both) - behavior will depend on platform and in some environments it will work, in some not.
Supposing I have a windows app developed based on C#. I want to ensure that it works on 32 bit and 64 bit both. But I don't want to change the config settings or application settings time and again. Is there a way to test both variants?
There are a couple of options.
You can target AnyCPU. If you're program is 100% C#/managed code, with no native dependencies, this will cause it to run 64bit on 64bit Operating systems and 32bit on 32bit Operating systems.
Target x86. This will cause it to run 32bit everywhere, which works properly on 64bit Windows (via WOW64). This works properly if you're using native (32bit) libraries, as well.
Make two builds, and two separate deployments. This allows you to use native code and still run 64bit on 64bit operating systems, but is far more work.
Since 32bit applications run well on 64bit operating systems, there is rarely reason to run the program natively in 64bit. This is typically only really beneficial if you're processing large amounts of data and truly need access to larger memory space than you can get in 32bit processes. In .NET, this typically means you'll want to build 64bit if you're going to use more than 1.2-1.6gb of RAM for your program. Otherwise, 32bit will work fine everywhere.
If you target AnyCPU, most .NET programs will run unaltered on 32-bit or 64-bit machines. The code will be jitted to 32-bit or 64-bit code as appropriate for the target operating system.
The exception where you need to use care is when using interop to unmanaged code.
If you do interop to unmanaged code and require to run as 64-bit on a 64-bit platform, you will have to make two builds.
If you do interop to unmanaged code and can accept running as a 32-bit process, target x86. That avoids two builds, and will run your .NET code as a 32-bit process in 32-bit and 64-bit platforms.
I have the 32 bit compiled dll when I try to use it in 64 bit application it fails to load,
So I would like to convert the dll to 64 bit. Its working fine when the platform of the application changed from "Any CPU" or "x64" to "x86". But I want to use it under 64 bit, Since I am going to call the dll from ASP pages.
Please help me out with this.
Windows CAN NOT load a 32bit dll into a 64bit process - this is a limitation that you can not circumvent. This means that if your 32bit DLL does any P/Invokes to other 32bit DLLS (or uses any 32bit .Net DLLS) you will be entirely out of luck (you will need to run the entire website in 32bit).
You are not entirely clear on when it works and when it doesn't. Here are the explanations:
x86 - 32bit - Can not be loaded into a 64bit process.
x64 - 64bit - Can not be executed on a 32bit machine.
AnyCPU - dual - Can be loaded and executed in both environments.
In terms of AnyCPU:
64bit process on 64bit machine - DLL is loaded as 64bit.
32bit process on 32bit machine - DLL is loaded as 32bit.
32bit process on 64bit machine - DLL is loaded as 32bit.
In most cases it's fine to leave it as AnyCPU. However, as I said, if you are using any native or .Net 32bit DLLs you will need to make your entire application 32bit (and there is nothing you can, or Microsoft could, do about this).
x86 flag is usually set for a reason, so it may be bad idea to change it. But if you are absolutely sure, there's an utility, corflags.exe. I have it under C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin. Of course it will help with .net assemblies only.
If you want to load a pure C# DLL in both a 32 and 64 bit process, then the correct choice is AnyCPU. This will compile it the DLL as CPU agnostic and it will be loadable into either type of process.
I'm not 100% sure that's what you're asking though. If it's not can you clarify your question?
you can take a look at http://msdn.microsoft.com/en-us/library/ms164699%28VS.80%29.aspx