We Keep Coding

Reference to com dll in c# What if COM is unregistered

I want to use third-party COM dll in my c# project. I've added "Reference" in Visual studio and got access to the COM types. All works fine.
Question: What if target machine where end-user will work has no that COM dll installed?
My app will not run at all or I can handle this situation safely somehow?

It works the same way as when you run your program with a missing .NET assembly, you'll get an exception when you try to create an instance of the object. The underlying COMException is for error code 0x80040154, "Class not registered".
This is easily tested btw, just unregister the COM server with Regsvr32.exe, /u option. Writing excessive amounts of code to deal with a missing DLL isn't typically that useful, given how easy it is to fix the real problem.

The binaries to your program should contain all the necessary libraries that you are using. It's all in the bin folder. If you give the computer everything that's in there your program will work fine.

System.DllNotFoundException in .NET DLL

I took a program written in C/C++ and modified it's main function to accept some arguments as input and return a variable as output and created a Win32 DLL out of it. I then created a .NET DLL which uses InterOp to access the first DLL. Now when I load the .NET DLL in my C# app I get a System.DllNotFoundException from the DLL which is really baffling me as there were never memory issues with the program and both Win32/.NET dlls are located in the same directory (apart from modifying the main function, the code has not really changed).
The solution was provided in this thread, which was my original question some time ago. I'm pretty sure that answer is correct but I'm just missing something.
You can download my VS solution Here. The solution contains three projects: the Win32 DLL, the .NET DLL, and a winform app that references the .NET DLL (but when trying to test gives the DLL exception). Any help or debugging guidance would be greatly appreciated.
UPDATE: I have tried all the tips/suggestions below but I still get the exact same error. If it makes things easier, my VS solution is available to download in the hyperlink above.

Make sure you have placed the win32 dll on /windows/system32 folder(if only the dll name is passed to DllImport)
Alternatively you can also pass the full path of the dll to the DllImport Attribute.
Use a tool such as Dependency Walker to make sure you are not missing out on any dependent assembly.

Which configuration do I need to use an external DLL in a WinForms application?

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%.

Win 7 DllImport C# Odd error, Invalid access to memory location?

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

C# to C++/CLI to C DLL System.IO.FileNotFoundException

I'm getting System.IO.FileNotFoundException: The specified module could not be found when running C# code that calls a C++/CLI assembly which in turn calls a pure C DLL. It happens as soon as an object is instantiated that calls the pure C DLL functions.
BackingStore is pure C.
CPPDemoViewModel is C++/CLI calling BackingStore it has a reference to BackingStore.
I tried the simplest possible case - add a new C# unit test project that just tries to create an object defined in CPPDemoViewModel . I added a reference from the C# project to CPPDemoViewModel .
A C++/CLI test project works fine with just the added ref to CPPDemoViewModel so it's something about going between the languages.
I'm using Visual Studio 2008 SP1 with .Net 3.5 SP1. I'm building on Vista x64 but have been careful to make sure my Platform target is set to x86.
This feels like something stupid and obvious I'm missing but it would be even more stupid of me to waste time trying to solve it in private so I'm out here embarrassing myself!
This is a test for a project porting a huge amount of legacy C code which I'm keeping in a DLL with a ViewModel implemented in C++/CLI.
edit
After checking directories, I can confirm that the BackingStore.dll has not been copied.
I have the standard unique project folders created with a typical multi-project solution.
WPFViewModelInCPP
BackingStore
CPPViewModel
CPPViewModelTestInCS
bin
Debug
Debug
The higher-level Debug appears to be a common folder used by the C and C++/CLI projects, to my surprise.
WPFViewModelInCPP\Debug contains BackingStore.dll, CPPDemoViewModel.dll, CPPViewModelTest.dll and their associated .ilk and .pdb files
WPFViewModelInCPP\CPPViewModelTestInCS\bin\Debug contains CPPDemoViewModel and CPPViewModelTestInCS .dll and .pdb files but not BackingStore. However, manually copying BackingStore into that directory did not fix the error.
CPPDemoViewModel has the property Copy Local set which I assume is responsible for copying its DLL when if is referenced. I can't add a reference from a C# project to a pure C DLL - it just says A Reference to Backing Store could not be added.
I'm not sure if I have just one problem or two.
I can use an old-fashioned copying build step to copy the BackingStore.dll into any given C# project's directories, although I'd hoped the new .net model didn't require that.
DependencyWalker is telling me that the missing file is GPSVC.dll which has been suggested indicates security setting issues. I suspect this is a red herring.
edit2
With a manual copy of BackingStore.dll to be adjacent to the executable, the GUI now works fine. The C# Test Project still has problems which I suspect is due to the runtime environment of a test project but I can live without that for now.

Are the C and C++ DLLs in the same directory as the C# assembly that's executing?
You may have to change your project output settings so that the C# assembly and the other DLLs all end up in the same folder.
I've often used the Dependency Walker in cases like this; it's a sanity check that shows that all the dependencies can actually be found.
Once your app is running, you may also want to try out Process Monitor on the code you are running, to see which DLLs are being referenced, and where they are located.

The answer for the GUI, other than changing output settings, was the addition of a Pre-Build Step
copy $(ProjectDir)..\Debug\BackingStore.* $(TargetDir)
The answer for the Test projects was to add the missing DLL to the Deployment tab of the testrunconfig. You can either do so by directly editing the default LocalTestRun.testrunconfig (appears in Solution under Solution Items) or right-click the Solution and Add a new test run config, which will then appear under the main Test menu.
Thanks for the answers on this SO question on test configurations for leading me to the answer.

The reason why this happens is because you either are loading DLLMAIN from managed code, before the CRT has an opportunity to be initialized. You may not have any managed code, be executed DIRECTLY or INDERECTLY from an effect of DllMain notifications. (See: Expert C++/CLI: .Net for Visual C++ Programmers, chapter 11++).
Or you have no native entrypoint defined wahtsoever, yet you have linked to MSVCRT. The CLR is automatically initialized for you with /clr, this detail causes a lot of confusion and must be taken into account. A mixed mode DLL actually delay loads the CLR through the use of hot-patching all of the managed entry point vtables in your classes.
A number of class initialization issues surround this topic, loader lock and delay loading CLR are a bit trickey sometimes. Try to declare global's static and do not use #pragma managed/unmanaged, isolate your code with /clr per-file.
If you can not isolate your code from the managed code, and are having trouble, (after taking some of these steps), you can also look towards hosting the CLR yourself and perhaps going through the effort of creating a domain manager, that would ensure your fully "in-the-loop" of runtime events and bootstrapping.
This is exactally why, it has nothting todo with your search path, or initialization. Unfortunately the Fusion log viewer does not help that much (which is the usual place to look for .NET CLR assembly binding issues not dependency walker).
Linking statically has nothing todo with this either. You can NOT statically link a C++/CLI application which is mixed mode.
Place your DLLMAIN function into a file by itself.
Ensure that this file does NOT have /CLR set in the build options (file build options)
Make sure your linking with /MD or /MDd, and all your dependencies which you LINK use the exact same CRT.
Evaluate your linker's settings for /DEFAULTLIB and /INCLUDE to identify any possiable reference issues, you can declare a prototype in your code and use /INCLUDE to override default library link resolution.
Good luck, also check that book it's very good.

Make sure the target system has the correct MS Visual C runtime, and that you are not accidentally building the C dll with a debug runtime.

This is an interesting dilemma. I've never heard of a problem loading native .DLLs from C++/CLI after a call into it from C# before. I can only assume the problem is as #Daniel L suggested, and that your .DLL simply isn't in a path the assembly loader can find.
If Daniel's suggestion doesn't work out, I suggest you try statically linking the native C code to the C++/CLI program, if you can. That would certainly solve the problem, as the .DLL would then be entirely absorbed into the C++/CLI .DLL.

Had the same problem switching to 64-bit Vista. Our application was calling Win32 DLLs which was confusing the target build for the application. To resolve it we did the following:
Go to project properties;
Select Build tab;
Change 'Platform target:' option to x86;
Rebuild the application.
When I re-ran the application it worked.