I have a simple program that makes a call via JNI to a DLL wrote ini C#.
Now when I run my servlet on Tomcat within a 32 Bit JVM, on a 64 bit PC, is the bitness of the DLL driven by the bitness of the JVM or of the Underlying hardware.
ie, Do I need a 32 bit or 64 bit version of the DLL?
Match the JVM, 32-bit JVM = 32-bit DLL.
Related
Is it OK for a COM DLL to be compiled as AnyCPU and work with both 32 bit and 64 bit applications?
Yesterday I started writing a C# COM DLL so that my MFC project could use the DLL. The DLL itself is for using the GMail API.
Initially I was compiling the DLL as either x86 or x64 and both of my executables were running fine.
Then I decided to change the DLL to compile as AnyCPU and now when my program runs it says Class not registered.
Does the DLL have to be compiled for each Bit edition then?
No, you can keep the .DLL compiled as "Any CPU" (in fact I certainly recommend it as long as you can), but you must register it in each version of the registry, so for example using regasm:
64-bit:
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe ClassLibrary1.dll /codebase /tlb
32-bit:
c:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe ClassLibrary1.dll /codebase /tlb
I've read about running 32 bit DLLs in 64 bit environments, especially here. But I'm still getting errors. Here's what I have. I have a real old 32-bit DLL that can't be converted to 64 bit. I have another DLL, my own, written in VB.NET, that I've compiled as x86. It calls the older one. My DLL is part of a Windows Service which I've compiled to x86 as well. So all x86 running on a 64-bit Win2012 server. The older DLL is actually installed on the machine itself, not part of my DLL or the Win Svc because of the nature of that DLL.
The older DLL is invoked using the standard X = CreateObject("oldDLL"). Everything works until I try to call a method on X. Then the method can't be found.
Any thoughts?
I have created simple BHO with ATL using these instructions
http://msdn.microsoft.com/en-us/library/bb250489(v=vs.85).aspx. I am creating both 64 bit and 32 bit dll of the dll. The problem happens when I try to to unregistered the 64 bit dll after the 32 bit version using regsvr32, I am getting 0x8002801c error.
(If I try vise versa the same problem happens). I have added images to celrify.
I think it has something to do with TypeLib registration because I it does the same thing for the 64 bit and 32 bit with no difference, after registering the 32 bit i have these two keys
HKEY_CLASSES_ROOT\TypeLib{5EA5008F-7766-499D-B4B0-9A671C752333}\1.0\0\win32 default = C:\programming\vswork\testfile\test64atlcom\Debug\test64atlcom.dll
HKEY_CLASSES_ROOT\Wow6432Node\TypeLib{5EA5008F-7766-499D-B4B0-9A671C752333}\1.0\0\win32 default = C:\programming\vswork\testfile\test64atlcom\Debug\test64atlcom.dll
Why does this happens, and how can solve it?
The error code is TYPE_E_REGISTRYACCESS. A typical problem with VS projects is that default template does not have x64 configuration and it's copying from Win32 does not update target environment in MIDL settings.
x64 build with Win32 would load and run, however it's registration would still COM-register the type library as 32-bit and cause 32/64-bit build collision.
So, you need to make sure that type libraries in Win32 builds target 32-bit, and x64 builds have them target 64-bit environment.
I have a C++/CLI assembly that wraps a native 32-bit dll.
The assembly is used both from .Net and COM (office).
Now I have a customer that runs 64-bit office.
Is it possible to create a C++/CLI assembly that uses a native 32-bit dll and exports a 64-bit com interface?
No, you can't mix code with different bitness in one process on Windows. You need to force 32-bit code into a separate process or convert that DLL.
The latter can likely be achieved by using COM+ (or DCOM which is mostly the same). This is what we usually do with native C++ code. I'm not sure about how easy it is with C++/CLI assemblies.
In a manner of speaking, yes.
Continue to compile the C++/CLI code as 32-bit so it can use the native library using C++ interop.
Then you will have to configure it to load as an out-of-process COM server when acting as an Office 64 plugin. With native COM code, midl automatically generates the 64-bit proxy. There should be some similar capability to create a proxy when registering .NET classes marked COMVisible.
The 64-bit COM interface will be contained in the auto-generated 64-bit proxy DLL, so this doesn't violate the rule that the bitness of all modules in a process must be the same.
I've built and installed my service from vs2010 onto a 64bit machine.
My problem comes in when my service references 32 bit dlls (spssio32.dll to be precise) - I get the error in my event viewer : "System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)"
Any help on the matter would be appreciated.
Regards,
Byron Cobb.
Is your service code written in a .NET language? If so, you need to mark it as targeting x86 rather than Any CPU (via Project properties / Build / Platform target).
(By default, .NET code targets Any CPU, meaning that on 64-bit machines it will compile into x64 machine code. Because such 64-bit code can't load 32-bit DLLs, that can lead to failures like the one you're seeing. Where code has a dependency on a 32-bit DLL, it needs to always compile to 32-bit machine code even on 64-bit machines, hence setting the target platform to x86.)
You can use a COM surrogate
http://www.dnjonline.com/article.aspx?id=jun07_access3264
The other variant is to spawn an external 32 Bit server-process and add a .NET remoting interface to it and your 64 bit application, so you can use .NET remoting for interprocess communication.