Let me describe my problem as well as I can.

I have a C# application program, let's call it App.exe. It references a DLL named A.dll which in turn references another DLL, namely, B.dll. However the way in which they are referenced is a bit different. In the code of A.dll, it has directly referenced B.dll (by going to Project > References > Add B.dll). However my App.exe has code to load A.dll at runtime using Assembly.Load() etc.

So to recap, App.exe ---- (runtime loading) ---> A.dll ---- (direct reference) ---> B.dll

All three things (App.exe, A.dll and B.dll) reside in the same directory, lets say ExeDir. Now what I want to do is, put A.dll and B.dll in a sub directory of ExeDir. I can do this by using an App.config file that specify the path of A.dll and asking the App.exe to load A.dll from that path. So far so good.

However the problem is, when I do this .NET gives me an error saying that it cannot find B.dll which is in the same directory as A.dll. If I move it back to hte original directory (teh same directory as App.exe) then it works fine. Which means, I can put A.dll in a sub directory, but the B.dll needs to be in the original directory.

Is there any way in which I can keep both DLLs in the sub directory

Your application may need reference to B.dll as well as A.dll since A.dll is referencing B.dll; I'm not 100% sure, but if you haven't tried it then do so. Sometimes the answers we're looking for are the simplest ones we don't try because we think that it can't possibly be the solution.

Your application may need reference to B.dll as well as A.dll since A.dll is referencing B.dll; I'm not 100% sure, but if you haven't tried it then do so. Sometimes the answers we're looking for are the simplest ones we don't try because we think that it can't possibly be the solution.

I don't think lack of referencing is the problem. Rather, the actual location of the DLL is the problem. Because as I have mentioned in the original post, when I move B.dll to the same folder as the App.exe, it works just fine.

Do you have the source code for any of the original .EXE?

The problem is caused by how the system looks for DLL files. It checks the location where the exe was started, the path, and the windows system directory. Since your DLL isn't located in any of these places, it can't find it. But you can register the DLL with the system. Use

regsvr32 "path to dll"

So if your DLL was in "C:\mydirectory\mysubdirectory" as was called "B.DLL" you use

regsvr32 "C:\mydirectory\mysubdirectory\B.DLL"

If it's an old DLL (pre .Net) you need to use regasm "path to dll" /codebase /tlb:YourTLBFileName.tlb. This will register it for a COM interop. I think the default place that programs look for dlls (unregistered ones) is in Windows\System32. If you really want, try just copying the DLLs there.

I also figured out probably the best way to go about this.

Add a <probing> element in your app.config:

http://msdn.microsoft.com/en-us/library/823z9h8w.aspx

<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>

For example, in the MSDN example the binder will search in the BIN folder by default, but will also search the bin2 folder, the bin2\subbin folder, and the bin3 folder. Replace bin;bin2\subbin;bin3 with the folder (relative to the EXE) that A.dll and B.dll are in. Note that you no longer have to specify the path to A.dll if it is included in the probing path.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.