I have written a COM control in c# .Net 4.5, this COM control uses a 3rd party dll to communicate with a USB device.
On Windows 7 32bit everything works 100% from both VBScript and the VB6 app. On Windows 7 64bit the VBScript fails when calling the 3rd party dll function that uses the USB device.
The exception is: "System.AccessViolationException" with message: "Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
What I don't understand is that the same COM control (and the same USB driver) works when instantiated from the VB6 app, but not from the VBScript.
I have looked at the loaded assemblies and registry access using Process Monitor when running the VB6 app and the VBScript but I cannot see anything out of the ordinary.
Any suggestions of what I can troubleshoot or test next?
Here's the deal. Applications written from VB6 are 32-bit. Your application works on 32-bit Windows and from a VB6 app on Windows 64 (which is running as 32-bit, since VB6 produces 32-bits. So, we know that your DLL works with 32-bit applications.
The thing is, when you run a VB script on Windows 64, it runs as a 64-bit process and you have a mismatch with your 32-bit DLL. If you run the VB script with the 32-bit version of the VB script engine (c:\windows\syswow64\wscript.exe or c:\windows\syswow64\cscript.exe) does it work? It probably will.
Now, if you compiled your DLL with the AnyCPU processor setting, then you can still register your DLL and get it to work with a 64-bit process. Just be sure to use the regasm.exe that is in the 64-bit hive.
For example register your DLL as such,
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe /tlb /codebase c:\path\to\yourdll.dll
Related
I have created a COM DLL using C#.NET 4.6 and exported class does have all attributes to be exposed as a COM interface. It is built using x64 platform target and registered using "Register for COM interop" flag under project's build option. Inside Microsoft Excel's VBA 64-bit it can be consumed without any issues.
But, I also need to consume this same COM in a Delphi 7 app but Delphi 7 only accepts 32-bit COM references. This app can't be migrated to a more recent version of Delphi though so I need to make this COM component to also work with 32-bit clients.
If I build the same C# DLL targeting x86 platform, it will be visible and functional in Delphi 7 but will stop working in Microsoft Excel VBA 64-bit client.
I understood making a 32-bit client to work with a 64-bit COM server can be done using Surrogates and WOW registry entries but even following these guidelines (Hosting a .NET DLL as an Out-Of-Process COM Server (EXE)) to create extra Windows Registry entries in *HKLM\SOFTWARE\Wow6432Node* it doesn't work (I know this is an old post but thought it would still be valid).
I'm running a Windows 10 x64 machine. Am I missing any additional step? Any tips would be appreciated!
Thank you!
It seems "AnyCPU" does the trick when you UNcheck "Register for COM Interop" in project settings.
To register it on user's machine, I'm running this with Admin rights:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe /tlb /codebase "C:\MyCOM.dll"
C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe /tlb /codebase "C:\MyCOM.dll"
Then, to remove (also as Admin):
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe "C:\MyCOM.dll" /u
C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe "C:\MyCOM.dll" /u
But, it seems some entries are left behind in registry.
Isn't "/u" enough for unregistering it?
Thank you.
For my job I need to use a 32 bit c++ dll with a 64bit c# program. I wanted to try doing this using dlls as wrappers.
What I have done for the moment is I made a dll that uses dll import to expose the function of the c++ dll and then make it COM+ enabled to make these functions available in 64 bit.
The problem I am facing is using this COM+ dll. To do it I followed this documentation
I signed it with a strong name, compiled it, registered it using gacutil and then sent it to com+ with Regsvcs. But when I want to use it I need to have a reference about it in my 64 bit app.
I tried to do add reference, select COM and then my class and it tells me that:
the ActiveX type library was exported from a .net assembly and cannot be registered.
If I try to add the tlb file it tells me:
check that the file is accessible and this is an assembly or a valid COM component
If I had the dll as reference, I get a badImageException.
My computer is not in English so the messages might not be accurate.
You cannot load a 32-bit DLL in a 64-bit process (nor the other way around). Wrapping it around COM can only help if the COM server is out-of-proc (i.e. an executable). If it's an in-proc COM server (i.e. a DLL), as I understood from your description, that's not going to work. Your 64-bit process will load the 64-bit COM server and then this will try to load the 32-bit DLL and that will fail. What you need to do is to change the COM wrapper into an out-of-proc server. That will run in its own 32-bit process. Communication with proper data marshaling between the 32-bit and the 64-bit process is done transparently through COM.
I have .NET assembly.
I am trying to register it for COM interop so that I can call it from VBA, using the following command:
regasm foo.dll /tlb:foo.tlb /codebase
When I did it on my pc, I could use it without any kind of problem. The code in VBA worked. The problem is when I regasm (with the same sentence) in other pc, it seems registering well (regasm says it) but when I execute the code in VBA, it throws an error for not finding the type. Reference is mounted correctly.
Start up Excel. Go to task manager and find it in the list of processes. If it says "excel.exe" then you are running a 64-bit process (or 32-bits if on a 32-bit OS). If it says "excel.exe *32", then you are running a 32-bit process on a 64-bit OS.
I expect that the problem is because you are running a 64-bit version of Office.
So, steps:
Find cmd.exe and launch it as Administrator -- you have to have elevated privileges
Run the 64-bit version of regasm.exe when you register. For a normal installation, "c:\windows\Microsoft.Net\Framework64\v2.0.50727\regasm.exe foo.dll /tlb /codebase". If you build it against another version of .Net, use that version instead of 2.0.50727.
I'm a bit of a beginner to C# and I've recently built a Windows Form Application GUI which executes a MATLAB function in much the same way as the answer presented here. So essentially using the Process.Start method to run the MATLAB function in the background.
This works fine with a 32-bit compiled MATLAB function, however compiling the function as a 64-bit executable leads to an error when executing from the WFA GUI - "Could not find version 8.2 of the MCR. Attempting to load mclmcrrt8_2.dll."
If I run the compiled function outside of the WFA GUI I have no problems. So it seems that the WFA cannot execute 64-bit processes, is there a workaround for this?
Thanks for any help.
You cannot have both MATLAB and MCR installed on the same machine and consistently run at deployed app.
I have not had any luck if both x32 and x64 MCR are installed, but you can have different version of the MCR installed, although that's not optimum.
If you have an x64 MCR deployed MATLAB, you must use x64 in your c# app.
This is not clearly documented, and these are from my experience deployed the same MATLAB base as a COM DLL, an x32 .NET assembly, and an x64 C++ shared library.
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.