I've created a custom exception class that is marked Serializable and
implements the ISerializable interface. I am throwing this custom exception
across my remoting boundary. It works just fine when the remoting client is
a Windows forms or console application, but if I use a .NET COM-exposed DLL
as my remoting client, I get a serialization exception:

System.Runtime.Serialization.SerializationExceptio n: Cannot find the
assembly ExceptionTest, Version=1.0.2456.29148, Culture=neutral,
PublicKeyToken=0ed9985891f0d0ea.\r\n\nServer stack trace: \n at
System.Runtime.Serialization.Formatters.Binary.Bin aryAssemblyInfo.GetAssembly()\r\n
at
System.Runtime.Serialization.Formatters.Binary.Obj ectReader.GetType(BinaryAssemblyInfo
assemblyInfo, String name)\r\n at
System.Runtime.Serialization.Formatters.Binary.Obj ectMap..ctor(String
objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[]
typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32
objectId, BinaryAssemblyInfo assemblyInfo, SizedArray
assemIdToAssemblyTable)\r\n at
System.Runtime.Serialization.Formatters.Binary.Obj ectMap.Create(String name,
String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[]
typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32
objectId, BinaryAssemblyInfo assemblyInfo, SizedArray
assemIdToAssemblyTable)\r\n at
System.Runtime.Serialization.Formatters.Binary.__B inaryParser.ReadObjectWithMapTyped(BinaryObjectWit hMapTyped
record)\r\n at
System.Runtime.Serialization.Formatters.Binary.__B inaryParser.ReadObjectWithMapTyped(BinaryHeaderEnu m
binaryHeaderEnum)\r\n at
System.Runtime.Serialization.Formatters.Binary.__B inaryParser.Run()\r\n at
System.Runtime.Serialization.Formatters.Binary.Obj ectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, IMethodCallMessage
methodCallMessage)\r\n at
System.Runtime.Serialization.Formatters.Binary.Bin aryFormatter.Deserialize(Stream
serializationStream, HeaderHandler handler, Boolean fCheck,
IMethodCallMessage methodCallMessage)\r\n at
System.Runtime.Serialization.Formatters.Binary.Bin aryFormatter.UnsafeDeserializeMethodResponse(Strea m
serializationStream, HeaderHandler handler, IMethodCallMessage
methodCallMessage)\r\n at
System.Runtime.Remoting.Channels.CoreChannel.Deser ializeBinaryResponseMessage(Stream
inputStream, IMethodCallMessage reqMsg, Boolean bStrictBinding)\r\n at
System.Runtime.Remoting.Channels.BinaryClientForma tterSink.DeserializeMessage(IMethodCallMessage
mcm, ITransportHeaders headers, Stream stream)\r\n at
System.Runtime.Remoting.Channels.BinaryClientForma tterSink.SyncProcessMessage(IMessage
msg)\n\nException rethrown at [0]: \n at
System.Runtime.Remoting.Proxies.RealProxy.HandleRe turnMessage(IMessage
reqMsg, IMessage retMsg)\r\n at
System.Runtime.Remoting.Proxies.RealProxy.PrivateI nvoke(MessageData& msgData,
Int32 type)\r\n at MyTest.Remoting.SampleObject.HelloWorld() in
c:\\documents and settings\\gpetros\\my documents\\visual studio
projects\\sampleobject\\sampleobject.cs:line 27\r\n at
MyTest.Remoting.SampleClient2.Test() in c:\\documents and
settings\\gpetros\\my documents\\visual studio
projects\\sampleclient2\\sampleclient2.cs:line 59

I've tried quite a few different solutions (after reading dozens of posts
and articles) with no success. I've tried different providers and
formatters, I've made sure my TypeFilterLevel is set to Full. The only thing
I can think of is that somehow COM Interop is messing things up. Any help is
greatly appreciated. If necessary, I can post my sample code that produces
this problem, just let me know. Thanks.

Greg Petros
Software Developer
Prime ProData, Inc.

Solved my problem on this one...

I was using a VBScript (.vbs file) to test the COM interface, which meant
that the wscript.exe process was running in the Windows\System32 folder. The
assembly containing my custom exception was not installed in the GAC, nor was
it accessible in the path (or Windows\System32), thus the error. This also
explains why it worked fine when I used a console or Windows app, since the
assembly containing the custom exception was right there in the working path.
My advice: Be aware of the working path that the actual executable that is
running.

"GP" wrote: