Similar to this issue, I have MS VC 2013 Express and successfully installed .Net framework. I have a solution with code mixed between c++ and c# (with managed code enabled.)
I want to create a static library from my code. Now I can create a dynamic library without any problem, but I get this error message during compiling my code:
fatal error C1107: could not find assembly 'mscorlib.dll': please
specify the assembly search path using /AI or by setting the LIBPATH
environment variable
I added the lib and its path by hand, and all other options suggested by MS pages, but there is still no solution.
My questions:
Can even I have static lib with mixed code? How I can create static lib only from my C++ code which uses C# code?
(Furthermore, when I change from x86 to x64 in the project properties the Linker menu changes to Librarian, why?)
EDIT:
Finally I could solve this issue. First of all I also think to create only pure static lib is not possible. I changed to dynamic lib. As soon as I have more clarified info considering my question I write here.
I am porting an application from Windows to Ubuntu written in C#. The application is used to view video from a capture card. I have had to write a C# wrapper for a Dll in windows to access the API for the card, and have written a Wrapper for the corresponding .so in Mono for Ubuntu.
To build and run a C example app for the .so in ubuntu I had to pass "-rdynamic" to gcc to make the application run correctly, else there would be errors such as "Undefined symbol: XMoveWindow". When I try to run my C# app I get "undefined symbol: XvShmCreateImage". I suspect that I need to pass something like "-rdynamic" to the compiler in mono, but I can't find an equivalent command for mono. Is there an equivalent command, and if so what is it?
Thanks in advance
Andrew
This likely means that your .so library is miscompiled (it's not referencing the X11 libs).
You should either recompile this .so lib correctly or you can P/Invoke some function inside libX11 and libXshm before invoking this lib (the functions need not exist, but in that case you need to catch the exceptions, this is needed to load the libraries in the process so that the loader later can find the symbols exported by them).
I am programming an application in Python which has to use some DLLs originally created from C# code. Generally the usage of such DLLs is working (proven with multiple DLLs, all from the same source). For deployment on other people computers I'm using Py2Exe which also works as intended.
But now I want to use another DLL and have the following problems. If I start the programm and make a call to a function within the DLL, it throws an error saying:
.Net Dll broken because of possibly missing native Dlls.
Now comes the strange part. If I compile the python program into an executable the message does not show up and everything works as intended.
I already tried to identify missing DLLs by comparing the DLL assembly with the ProcessExplorer but they look totally the same. Next thing was to try to set path variables to all Dlls which I am calling directly but this was no solution too.
Other informations which could be interesting are IDE and OS: I'm using Eclipse Indigo with PyDev 2.5 plugin on a Windows 7 machine.
So are there any things I could have overseen or settings which I could try to make it work?
Any suggestions are appreciated.
I'm working with an external DLL to consume an OCR device using a wrapper written by me. I have made tests on the wrapper and it works perfectly. But, when I use a WinForms project to consume the client class of the wrapper (located an another project), an error arises when calling C# methods imported from the DLL (using [DLLImport(...)]) saying that the DLL is not registered.
The error says:
"DLL Library function no found. Check registry install path."
All executions have been made in debug mode.
I've compared both projects configuration. The most relevant difference is that Test project is oriented to Any CPU and WinForms app only points to x86.
What could it be?
Updates
I've tried to register the dll using Regsvr32.exe but it didn't work. I thought about using Gacutil.exe but it required to uninstall all frameworks beyond .net framework 1.1...
I was wondering... at testing environment probably everything works well because testing framework has its dll's or executable files (or something like that) totally registered in windows, so those are trusted dlls. It is possible that debug generated dlls are not trusted by windows and therefore this problem arises?
I've created a form in the same troubling project and then I call the OCRWrapper from a button I've added to it. The OCR's worked!!. Unfortunately, it is difficult to rewrite the first form because we have invested a lot of hours in it; so, I'm still wondering what do I need to change in the troubling form...
I started again the form's development from scratch and added all the components related to it; everything worked well, the OCR read succesfully all data. When I loaded a combo box using a call to an ObjectContext and the error appeared again... I'm using an entity framework connected to Oracle.
I have a theory.
Let's imagine the following situation:
The ocr.dll depends on some other native DLL, lets call it other.dll [A].
In case this is a static dependency, you'll see it through Dependency Walker.
If its dynamic, you can use Sysinternals Process Explorer to monitor DLL loading in your working test project at run-time.
Your ADO.NET provider uses native DLLs under the hood (this is certainly true for ODP.NET) which depend on other.dll [B], which happens to have the same name but is actually a different DLL (or at least a different version) compared to other.dll [A].
Then, in run-time, this might happen:
When you connect to the database, ADO.NET provider dynamically loads its native DLLs, including the other.dll [B].
Then you try to call a function from OCR DLL. The P/Invoke tries to load the OCR DLL dynamically and succeeds, but the other.dll [B] is already loaded and ocr.dll tries to use some function from it, instead from other.dll [A] where it actually exists.
Welcome to DLL hell. So what can you do?
Try varying the order of calls to ocr.dll and ADO.NET provider to see anything changes. If you are (very) lucky, other.dll [A] might actually be a newer version that is still backward-compatible with other.dll [B] and things migh magically start to work.
Try another version of ADO.NET provider.
Try another ADO.NET provider.
Try getting a statically-linked ocr.dll from your vendor (i.e. no run-time dependency on other.dll [A]).
So, the call to the DLL works from a single button, but it does not work from a complex form. I'd say that there is an undefined behavior going on. The question remains whether it is you, that wrote the marshalling incorrectly, or it the DLL that is badly written.
Since we do not have access to the source code of the DLL, maybe you can post the prototype of the function, and all relevant struct definitions, and the DllImport line that you wrote for it?
Google can't find that error message which means(not definitely though :)) it is not a system message but a custom one coming from the code in the dll. So the dll does something dodgy. I guess it tries to double dispatch your call to another function internally.
Few things I suggest you try:
Run a x86 configuration. In the project properties -> Build tab set the platform to x86. this is assuming the dll is an x86 dll.
dumpbin /headers orc.dll
File Type: DLL
FILE HEADER VALUES
14C machine (**x86**)
4 number of sections
4CE7B6FC time date stamp Sat Nov 20 11:54:36 2010
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
2102 characteristics
Executable
32 bit word machine
DLL
This command line should tell you the bitness. In case it is a 64 bit run a 64 bit config instead but I bet it is 32 bit.
Do not include the dll in the project. I guess you do that already. Make sure the dll is in a folder that is in the %PATH% environment variable. When you run this at command prompt:
where ocr.dll
should tell you where the dll is. If it doesn't add the folder where the dll is installed to the %PATH%.
I am using DllImport to access some functions in a C++ dll from my C# application.
This code works fine on my dev laptop, which is Windows 7 64bit, the dll itself is 32 bit, so I run the process hosting the dll in 32bit and it works well. However when I try to run the exact same process on my target machine, which is again, Windows 7 64bit Ultimate i get the error 'Invalid access to memory location.' from the process.
I'm not sure what the problem is, i've looked at loads of resources on the net and none of them have solved it for me. I dont understand why it works fine on my dev box, but not on the target?
The dll itself is fine, the examples that come with the dll all work fine on my target box (which are C# apps doing DllImport).
Has anyone else had this problem? Been fighting it for two days now!
Exception: {"Unable to load DLL 'CLEyeMulticam.dll': Invalid access to memory location. (Exception from HRESULT: 0x800703E6)"}
The DLL loading may crash because of unresolved dependencies, so open your DLL on target machine using Dependency Walker and see is there any problems.
I notice one big difference between your dev machine and your target machine, the dev environment. Make sure you have all the necessary redistributables on the target machine.
Edit: I have seen similar issues when some dlls were compiled to different versions of the .Net framework or if they were made with different versions of Visual Studio, as the redistributables for each version are different and the latest redistributables are not exactly backwards compatible.
I had the same problem here Native loading works good. Loading from .net gives error Unable to load DLL 'my.dll': Invalid access to memory location
The problem was in DEP feature. When I switched on DEP for essential programs only, it gave no effect. But when I completely switched off DEP, and rebooted my server, error has gone. The one more thing I've done - installed latest updates for .net 4.0
The one notable thing - i didn't see any errors about DEP, just closing with "memory" error.
I've had this issue before. I think your problem is with VS trying to open the file but not having permissions to read it. You need to make sure the account you're using has access to the DLL. Try disabling UAC to see if it works, or use an Administrator account. Or try giving Full Control on the DLL to Everyone.
EDIT: Could you run VS as administrator (right click -> Run As Administrator)? Could you put the DLL onto your desktop to try? Is there a folder structure difference between your working computer and the one that's failing? Also, can the DLL run fine if you execute it outside of VS (try running it as admin as well)?
HTH
I have had similar problems before, try the following.
Check the .NET CLR version. Are there any SPs/KBs present in your target that is not in your dev?
Try loading the debug version of the C++ DLL. Are you able to load it? If it fails, I'd suggest starting your app under WinDBG in your target. Once the exception is hit, a simply !analyze -v will give you lots of info.
As a next step, I'd try to reproduce this issue in a unit test environment. Are the C# samples you mentioned built for x64 VM? If not, try doing that and try running the resulting sample binary in your target. Is the issue reproducible?
I have encountered a problem with a 64bit .NET app ("Any CPU") trying to load a 32bit native DLL dependency. I don't have the error message in front of me, so I can't tell you if it is the same problem. The solution for my problem was to change my build to x86-only.
If the bit size of the DLL is changing on each box, maybe there are structure size differences, so your PInvoke signature becomes incorrect. This could easily cause a buffer overrun, and cause stack corruption in the native code.
If you're getting the error in your C# app, this message often indicates the native code did something nasty to memory that the ILM can see - check the code in/called by your DllMain routine - that is called before your call actually goes thru - if it's misbehaving, you'd see this result
#Merlyn Morgan-Graham We faced a similar problem. Where we built the .Net application with "Any CPU" build and tried using with 32 bit C++ Dll. When we run the .Net Application in 64 bit OS. It runs as 64 bit executable and hence and got similar issue. After buidling in X86 Loading, Calls to C++ Dlls worked absolutely fine. One more important thing is if you are using C++ DLL in your .Net code. There would be fair amount of marshalling, so it is important to stick to the build type (i.e. X86, any CPU or X64).
Please check the following link also:
Windows Vista: Unable to load DLL 'x.dll': Invalid access to memory location. (DllNotFoundException)
The obvious, but probably lame solution would be to build C# side explicitly for 32-bit. Check how do you create out of proc host - programatically or by populating registry keys or ... could be that on other box it gets set up to either make 64-bit hosting process or attempt in-proc invocation, which means loading ... It it's a registry setting don't forget that for mixed 23/64 bit cases there are two branches to dig into.
I ran into a similar issue when I moved to win7. You might need to set your (64 bit) machine to run as a 32bit one by-default, using the below command:
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe setwow
Ref:
http://social.msdn.microsoft.com/Forums/en/phoenix/thread/9a43e9a1-a744-4a1a-bb34-3604254c126b