Unable to find assembly 'Rebex.Net.Ftp'

0 votes
asked Oct 8, 2014 by Sreb (170 points)
edited Oct 10, 2014

I am using Rebex.Net.Ftp.dll and Rebex.Net.ProxySocket.dll in my WCF service which is deployed in a VM. I have a WPF client which uses the service to do ftp uploads. Ftp related functions work fine if i run client from my local. If I deploy client in a different machine and try to run, i am getting the following error in the service VM.

Here are the details, from event viewer.........

An unhandled exception occurred and the process was terminated.

Application ID: DefaultDomain

Process ID: 6408

Exception: System.Runtime.Serialization.SerializationException

Message: Unable to find assembly 'Rebex.Net.Ftp, Version=3.0.3484.0, Culture=neutral, PublicKeyToken=1c4638788972655d'.

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.ObjectMap.Create(String name, 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.CrossAppDomainSerializer.DeserializeObject(MemoryStream stm)
   at System.AppDomain.Deserialize(Byte[] blob)
   at System.AppDomain.UnmarshalObject(Byte[] blob)

2 Answers

+1 vote
answered Oct 9, 2014 by Tomas Knopp (58,890 points)
edited Oct 10, 2014

Hi,

it looks like a FtpException or some other Rebex defined exception occured in your program which was then serialized but the WPF client on the other side was unable to deserialize the FtpException because it did not have the needed Rebex.Ftp.dll reference.

So there are two possible soltutions:

  • either add the Rebex.Ftp.dll into the WCF client references
  • or add a try catch block and translate all Rebex exceptions to a system exception before serializing it, so that the WCF client will be able to deserialize them even without having the Rebex.Ftp assembly.

By the way you seem to be using a rather old version, could you share your support contract details with us?

0 votes
answered Oct 10, 2014 by Sreb (170 points)
edited Oct 10, 2014

Thanks Thomas.

We have identified the issue. At a later point of time we found that the exception was coming even when we ran the client from local machine. And the issue turned out to be the following code which does a async ftp transfer.

ftp.BeginPutFile(stream, remotepath, null, null); ftp.Disconnect();

in my opinion, the problem was with disconnect method call, which would have tried to disconnect while the file transfer is still on, and resulted in the exception mentioned above.

Though the exception looks unrelated, after replacing the async call with ftp.PutFile(), the issue did not occur again.

Can you please let me know, whether the BeginPutfile method takes care of disconnection also(by any rare chance)? If not then how to handle this scenario if we want to do an async file transfer.

commented Oct 10, 2014 by Tomas Knopp (58,890 points)
edited Oct 10, 2014

No, BeginPutFile method does not take care of disconnect.

The method only starts the async operation and immediately finishes (even if the started operation has not finished yet). Knowing this it's clear that your code will cause problems - the ftp.Disconnect() call won't be successful as there is a background upload going on.

A right solution would be to use a callback method (if you really want to go with the Begin/End async pattern) and call disconnect once the async transfer is finished. Please note that support for async/await pattern programming is available since the 2012R3 version.

...