2

I have a huge problem with implementing one of my DLL's.

This is the problem: I have a DLL, lets call it Common.dll, which is referenced in my c# project. This DLL calls another DLL called SoloistCore64.dll.

Furthermore I have a working sample program and my own. In my own program the Common.dll can not find the SoloistCore64.dll for some reason. In the sample program I have, everything works fine.

In both projects, both DLL's are in the same directory, all paths are correct in the property manager. The Reference for my Common.dll is recognized and works correctly.

There is only one differnce in the sample program in comparison to my own and i can't find out what it means.

This is how the reference looks in my own project. (not working) My own Program

My own program2

And this is how it looks in the sample program. (working)Sample Program

sample program I can only assume this blue icon indicates the reason why my reference is not working. Does anyone know what it means? I could not find it in the image library.

The exception says

InnerException: 
       HResult=-2146233052
       Message=Die DLL "SoloistCore64.dll": Module not found. (Exception HRESULT: 0x8007007E) can not be load.
       Source=Aerotech.Soloist
       TypeName=""
       StackTrace:
            bei Aerotech.Soloist.Core.Wrapper.dllUtilMachineConfOpenx64(IntPtr argument1, StringBuilder argument2)
            bei Aerotech.Soloist.Core.Wrapper.dllUtilMachineConfOpen(IntPtr argument1)
            bei Aerotech.Soloist.Communication.NetworkSetup..ctor()
            bei Aerotech.Soloist.Controller..cctor()
       InnerException: 

I placed the .dll in every possible directory but it did not work.

UPDATE: I now tried the following. I added all dll's to the system32 and syswow64 directory and now it works! I do not know why though,...my reference is in a completely different directory...

DerBenutzer
  • 311
  • 1
  • 5
  • 20
  • and what happens that it does not work? it does not compile? did you try to remove and add the reference to the dll SoloistCore? – mikus Jan 06 '16 at 11:42
  • Is your Solution 64bit? Or 32 bit...They need to be the same (unless you want to have complex bit shunting...) – Grantly Jan 06 '16 at 11:44
  • I tried to compile it in 64 bit. The project throws an exception that SoloistCore64.dll could not be found. – DerBenutzer Jan 06 '16 at 11:48
  • the second one, the blue icon means it's a hyperlink to another target. it's indeed would compiled successfully. But its not referenced correctly. – vantian Jan 06 '16 at 11:51
  • As @mikus said, what doesn't work? Does it not compile? Is application crashing? Can we assume that SoloistCore dlls are 32 and 64 bit dlls? How are you handling correct loading of those? – Rok Jan 06 '16 at 12:03
  • heh, now with the updates its finally visible that they were nto referenced at all, just included.. – mikus Jan 06 '16 at 12:57
  • Yes 64 means 64 bit. It's crashing, I added the exception to my post! – DerBenutzer Jan 06 '16 at 13:29
  • Thanks. It was my problem too. – Amin Jan 14 '19 at 15:51

2 Answers2

4

These are not references, most visible by them not being inside the References node of your project. The only point of adding DLLs to your project like this is to get them copied to the project's build directory. That's useful since your program can only run when the OS can find these DLLs. Their Build Action property should be "Content", their Copy to Output Directory property should be "Copy if newer".

The problem with the non-working version is that the DLLs get copied to the bin\Debug\libs directory. The OS has no idea that it needs to look in a subdirectory for any DLLs. You would have to help, like pinvoking SetDllDirectory() or adding the subdir to the Path environment variable.

Not a problem in the working version, the DLLs get copied to bin\Debug. The OS always first looks in the directory where the EXE is stored. This should always be your preference since it trivially avoids DLL Hell. If you hate them being visible in the project's toplevel node then use a post-build event to xcopy the DLLs.

You tend to have very painful [DllImport] when you need to make this work both in 32-bit and 64-bit code since the DLL names are not the same. Read this post for a solution.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • he should be able to keep them in libs folder and reference using relative path – mikus Jan 06 '16 at 12:58
  • i tried to use the solution by setting a new directory for the dll. It still says the dll is not found though.... but you are right it is nowhere to be found in the bin debug/release files. I also tried to place the dll right next to my .exe, but that did not work either, it is not found – DerBenutzer Jan 06 '16 at 13:20
  • You will also get this kind of error if the DLL itself has another DLL dependency. They very often do, like the C runtime DLLs. Run dumpbin.exe /imports to see that other DLLs are required. SysInternals' Process Monitor is also useful, you'll see your program searching for the missing DLL and not finding it. If you can't make sense of what you see then use a telephone to ask the owner of the DLL for the proper deployment procedure. – Hans Passant Jan 06 '16 at 13:29
  • I now tried the following. I added all dll's to the system32 and syswow64 directory and now it works! I do not know why though,...my reference is in a completely different directory. – DerBenutzer Jan 06 '16 at 13:37
  • Using the worst possible way to deploy these DLLs is not much of a solution. You are ignoring my advice, good luck with it. – Hans Passant Jan 06 '16 at 13:43
  • i already used a dependency walker on the dll, but it only found missing (warnings)dependencies for other system dlls. the owner of the dll cant be contacted right now unfortunately. i know its a shitty solution thats why i try to figure out how to do it the right way... – DerBenutzer Jan 06 '16 at 13:48
1

I solved the problem myself. The easiest way was to manually put the dll.s in the debug/bin and release/bin folders. However I added my two dotNet DLL's as reference. The unmanaged c++ DLL's where added as a link to the same project (Project->Add Existing Item->Dropdownmenu[Add as Link]). After that you have to set the 'Copy to Output' property of your DLL to 'Always Copy' and it works fine.

DerBenutzer
  • 311
  • 1
  • 5
  • 20