Hi Gaetan,

Thank you for the information. So, actually, you are facing two problems:

1. The Mydll2.dll loading problem. The behavior you are observing is 
caused by .NET Framework, and it cannot be changed. Here is how it works 
- if an assembly cannot be found in GAC, the system looks for the 
assembly in the application's folder or in its subfolders. In your case, 
the application is the tcHostingProcess.exe process of TestComplete 
which is started from your <TestComplete 7>\Bin folder. Here is what you 
can try: add Mydll2.dll to CLR Bridge in TestComplete before adding 
Mydll1.dll. If this does not help, give a strong name to Mydll2.dll (see 
the following page to learn how to do this: 
http://www.codeguru.com/columns/experts/article.php/c4643/) and make 
Mydll1.dll load Mydll2.dll by the strong name. In this case, the 
framework may use Mydll2.dll loaded into the tcHostingProcess process 
instead of trying to find the assembly in the application's folder.

2. The *.config loading problem. When you start working with CLR Bridge 
in your project, the working directory for the tcHostingProcess process 
is set to the project's directory. Therefore, if you try to load a 
".\Log.config" file, the file is supposed to be located in your 
project's directory. However, you can change the working directory 
explicitly using the following code:

[JScript]

dotNET.System_IO.Directory.SetCurrentDirectory("C:\\Temp\\myTestAssemblies");

--
Best regards,
Allen - AQA Support

Gaetan wrote:
> Hello,
> 
> Thanks for the feedback.
> 
> Regarding your suggestion, none of them worked.
> 
> Here a better explanation
> 
> I’ve got the following directories
> 
> DIR1 :   	C:\Program Files\Automated QA\TestComplete 7\Bin
> Where TestComplete.exe is installed.
> 
> 
> DIR 2 :	C:\Utils\Projet\DLL_Load\TestDLL\TestDLLProj
> TestDLL is my project suite
> TestDLLProj is my project 
> 
> DIR 3: 	C:\Temp\myTestAssemblies.
> Contains the DLL I want to test and  config files.
> Mydll1.dll
> Mydll2.dll
> Mycdll1.config
> Log.config
> 
> Mydll1.dll reads some configuration parameters from Log.config (using a relatives
> path)  and use some functions that are in Mydll2.dll.
> 
> 
> In TestComplete TestDLLProj CLR, I’ve included the patch to Mydll1.dll, so
> I can see the name space in my script.
> 
> 
> In order to have the script working I have to do the following:
> -copy the Log.config and the Mydll1.* under DIR2 so apparently the “relative
> path” is where the project is.
> 
> Copy all linked dll, (in this example Mydll2.dll) into DIR1. It seems here
> that “Application Base” for the path search is where testcomplete.exe is.
> 
> 
> Apparently the CLR in TestComplete does nothing else than making the namespace
> available in the script, it doesn’t link the reference to the other dll.
> 
> 
> Is there anybody that already try testing .net dll assemblies?  I would be
> interested about how they solved the linked dll problems (without having
> all assemblies being installed into the GAC)
> 
> Thanks.
> 
> 
> AutomatedQA Support <support@automatedqa.com> wrote:
>> Hi Gaetan,
>>
>> First of all, if you are using .NET Framework 1.1, please try updating 
>> to a newer version of .NET Framework (it looks like a known problem 
>> which is solved in .NET Framework 2.0 and its later versions). If this 
>> does not help, try adding all your .NET assemblies to CLR Bridge. If 
>> some DLLs are located in GAC, add them from GAC. If this suggestion does
> 
>> not help, please let us know the folders hierarchy in which the 
>> problematic files are located (that is, describe how the files are 
>> located relevant to each other). Also, we would appreciate it a lot if 
>> you provided us with a simple sample with which the problem can be 
>> reproduced (you can send it to us via our Contact Support form 
>> (http://www.automatedqa.com/support/message)).
>>
>> --
>> Best regards,
>> Allen - AQA Support
>>
>> Gaetan wrote:
>>> Dear All,
>>>
>>> I’ve got a question regarding .NET assemblies and the path to retrieve
> de
>>> dll.
>>>
>>> I’ve put in one directory all the DLLs and the needed config file that
> is
>>> required by my assembly. 
>>>
>>> In that directory I’ve got also a test.exe program that “load” the assembly
>>> and use it. 
>>> I can use it without problem.
>>>
>>> Then I wanted to use TestComplete to load the assembly and perform some
> automated
>>> test by using the dotNET object.
>>>
>>> So I’ve created a project and put in the “CLR Bridge” the  path to the
>  DLL.
>>> In the object browser I can see the name space of my assembly.
>>> Then in my code I’ve used the following
>>>
>>> Sub MyFirstTest
>>> dim abcd
>>> dim efgh
>>>
>>> set abcd =  dotNET.<the correct name space>.zctor
>>> set efgh = abcd.Connect("")
>>> …..
>>>
>>> I’ve tried to run this simple script and got multiple errors regarding
> location
>>> of various elements like config files and the “famous” Microsoft.Practices.Unity.dll
>>>
>>> First it seems that for the confi file , the “execution” path is the directory
>>> where the Testcomplete project is located.
>>>
>>> So I copied all my DLLs and config files into the directory where I’ve
> got
>>> my TestComplete project.
>>> So now the assembly seems to be able to find its config file.
>>> But now I’ve got errors like: Could not load file or assembly Microsoft.Practices.Unity.Configuration.
>>>
>>> But I do have the “Microsoft.Practices.Unity.Configuration.dll” in my
> directory.
>>> I’ve tried to copy this dll (Microsoft.Practices.Unity.Configuration.dll)
>>> next to the TestComplete.exe file and now the script seems happy, but
> now
>>> obviously is complaining about the others dependent dll.
>>>
>>> So my problem is that for some component the script is looking into “its”
>>> folder and for other the script looks the dll into the TestComplete.exe
> directory.
>>> So I don’t want to copy all my dlls into the TestComplete directory and
> I’m
>>> not really happy to fill the GAC with all the DLL as this is not reflecting
>>> the production situation.
>>>
>>> Any idea about how I can set the “search path” to the directory I want?
>>>
>>>
>>> Thanks.
>>>
>>>
>>>  
>>>
>