Update - Original Question Below
I've done some additional testing and I now believe that the source of my problems is how .NET is locating the assemblies.
As I mentioned below there are .dll files in subdirectories but the .dll files I mentioned below are not the only .dll files in each directory. For example, in the \translation\Customer directory there is a Customer.dll file and a couple standard files (Translation.dll, Mapping.dll, Execute.dll). In the \translation\Standard directory there is a Standard.dll and then the other standard files (Translation.dll, Mapping.dll, Execute.dll). These files are all generated code (from different projects) which is why each directory has copies of the standard files as well as a file that's directly related to the subdirectory.
When a method from the Customer.dll file is executed in my Windows Service application other methods in the standard assemblies (Translation.dll, Mapping.dll, etc...) will also be called. I believe that calls to other .dll files are not being executed on the .dll in the same directory.
For example, I call a method on /translation/Customer/Customer.dll and, in turn, that calls a method on Translation.dll. However, instead of the calling the method on /translation/Customer/Translation.dll the application is finding /translation/Standard/Translation.dll first and calling the method on that file.
Is it possible to force .NET to make calls to these associated .dll files within the same directory? Or do I have to do something to make the "standard" assemblies uniquely named in each directory?
Original Question:
I have a C# Windows Service application that monitors a directory and processes incoming files. Each file that gets processed has a configurable set of tasks run against the file. The code for each task is contained in an external .dll that is loaded dynamically at run time using reflection. The external .dlls exist in several subdirectories of the main application folder and access to them is granted via entries in the application's <probing> element in the app.config file.
I've recently expanded the number of subdirectories to better organize the external .dlls and I've encountered some unexpected functionality with the <probing> element. I am running a test to process a file that requires 2 tasks to be executed against the file. The first task exists in the file Customer.dll and is located in a subfolder called "\translation\Customer". The second task exists the file Standard.dll and is located in a subfolder called "\translation\Standard".
If my probing element looks like this <probing privatePath="translation\Customer;translation\Standard"> the second task (running a method on a .dll in the "Standard" folder) will fail to execute.
However, if I switch these entries so that the probing element looks like this <probing privatePath="translation\Standard;translation\Customer"> both tasks execute successfully.
Can anyone help me understand why the order of subdirectories in the probing element would have an effect on the execution of .dlls contained within those subdirectories?
Further investigation has revealed that this was not a reflection or assembly loading problem. The problems I was experiencing was due to build issues inside the assemblies I was reflecting on. The errors were obscure and it made the problem look like something it wasn't. Thanks to SWeko for noting to look into the inner exceptions. That comment helped a lot!!