Forum Discussion

PascalRoy's avatar
14 years ago

Test DLL not found?

Hi,



I'm testing TestComplete and I'm trying to use some of our existing .NET DLLs.



I added the DLL into the CLR Bridge configuration parameters and I am using it through the dotNET. object in my script.



So far, so good.



First, I'm calling this




  if (dotNET.Metrino_Protocol_Design_Instrument.InstrumentActivator.InstrumentProvider == null)

  {

    dotNET.Metrino_Protocol_Design_Instrument.InstrumentActivator.InstrumentProvider = dotNET.Metrino_Protocol_Design_Instrument.Pbg2ActivatorInstrumentProvider.zctor();

  }




and I know it works, so my DLL is loaded and used allright.



Then I call this:




  iTestInject = dotNET.Metrino_Protocol_TestCaseHandler_Instrument.TestInjection.GetInstance(instrument);



and using traces in the GetInstance() function, I can see that most of the processing is done, but when it reaches a point where this call is made:



  moduleManifests = detection.GetModuleCatalog();






I get an error upon *returning* from this function.



detection.GetModuleCatalog() is a function from another DLL (Metrino.Kernos.Platform), located in the same directory as the one I call (added into the CLR bridge).  Here is the error that I get:



An
exception occurred in the "Unit3" unit at line 14:

mscorlib

System.Runtime.Serialization.SerializationException: Unable to find assembly
'Metrino.Kernos.Platform
, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=02be2af3f10d9688'.



Server stack trace:

   at
System.Runtime.Serialization.Formatters.Binary.BinaryAssemblyInfo.GetAssembly()

   at
System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo
assemblyInfo, String name)

   at System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String
objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[]
typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32
objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable)

   at
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped
record)

   at
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryHeaderEnum
binaryHeaderEnum)

   at
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()

   at
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain,
IMethodCallMessage methodCallMessage)

   at
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
serializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallMessage methodCallMessage)

   at System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryResponseMessage(Stream
inputStream, IMethodCallMessage reqMsg, Boolean bStrictBinding)

   at
System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage
msg)



Exception rethrown at [0]:

   at
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessage retMsg)

   at
System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 type)

   at Metrino.Kernos.Platform.Detection.Detection.GetModuleCatalog(Type[]
manifestTypes)

   at
Metrino.Protocol.Design.Instrument.RemoteControlUtilities.GetModuleManifestCollection(Detection
detection, Type manifestType) in
C:\WS\SilverbackFP1\Instrument\Framework\InstrumentServices\DotNetWrapper\RemoteControlUtilities.cs:line
375

   at
Metrino.Protocol.Design.Instrument.RemoteControlUtilities.InvokeGetCatalog(String
serverAddress, Int32 port, Type manifestType, PlatformManifest&
platformManifest) in C:\WS\SilverbackFP1\Instrument\Framework\InstrumentServices\DotNetWrapper\RemoteControlUtilities.cs:line
201

   at
Metrino.Protocol.Design.Instrument.InstrumentConnection.connect(String
remoteServerAddress, Int32 remoteServerPort, String moduleAddress, Type
specificInstrumentType, Type specificModuleManifestType) in
C:\WS\SilverbackFP1\Instrument\Framework\InstrumentServices\DotNetWrapper\InstrumentConnection.cs:line
292

   at
Metrino.Protocol.Design.Instrument.InstrumentConnection..ctor(String
remoteServerAddress, Int32 remoteServerPort, String moduleAddress, Type
specificInstrumentType, Type specificModuleManifestType) in
C:\WS\SilverbackFP1\Instrument\Framework\InstrumentServices\DotNetWrapper\InstrumentConnection.cs:line
104

   at
Metrino.Protocol.Design.Instrument.InstrumentConnectionFactory.GetInstrumentConnection(String
remoteServerAddress, Int32 remoteServerPort, String moduleAddress, Type
specificInstrumentType, Type moduleManifestType) in
C:\WS\SilverbackFP1\Instrument\Framework\InstrumentServices\DotNetWrapper\InstrumentConnectionFactory.cs:line
114

   at
Metrino.Protocol.Design.Instrument.Pbg2ActivatorInstrumentProvider.GetInstrument(String
remoteServerAddress, String moduleAddress) in
C:\WS\SilverbackFP1\Instrument\PBG2\DotNetWrapper\Ftb400\Pbg2ActivatorInstrumentProvider.cs:line
21

   at Metrino.Protocol.Design.Instrument.InstrumentActivator.GetInstrument(String
remoteServerAddress, String moduleAddress, Boolean waitInitialization) in
C:\WS\SilverbackFP1\Instrument\PBG2\DotNetWrapper\Ftb400\InstrumentActivator.cs:line
56




What is confusing for me is that:




  1. This DLL is initially found, since I can see on my side that its code is executed (I see proof of that through traces in the code)

  2. I have copied the DLL into the C:\Program Files\Automated QA\TestComplete 8\Bin directory (where tcHostingProcess.exe is located) and the problem disappear.



How can I solve this issue without copying all of my DLLs into C:\Program Files\Automated QA\TestComplete 8\Bin?



I have added this DLL (Metrino.Kernos.Platform) to the CLR Bridge list, to no avail.



Thanks.

1 Reply

  • Hi Pascal,



    The issue is caused by the specifics of the .NET runtime's assembly resolving procedure. Since the dotNET calls are performed in the context of tcHostingProcess.exe, .NET considers it the "main" application and therefore looks for dependent assemblies in its folder. That's why, placing the assembly next to tcHostingProcess.exe solves the problem.



    To avoid copying the assemblies to the TestComplete folder, I recommend that you put them to the GAC instead.