开发者

Custom exception propagation in .NET Remoting fails with a TargetInvocationException saying "could not load the file or assembly"

开发者 https://www.devze.com 2023-01-19 17:27 出处:网络
I have a client server app which uses .NET Remoting to communicate. This is separated by an interface and the client doesn\'t reference the server\'s implementation. Now, a custom exception in a share

I have a client server app which uses .NET Remoting to communicate. This is separated by an interface and the client doesn't reference the server's implementation. Now, a custom exception in a shared dll, when thrown from the server isn't caught by the client and throws a TargetInvocationException saying "Could not load the file or assembly [Server Assembly]". The problem is solved if I copy the server assembly to the client. It is slightly odd that this happens given that the server assembly doesn't even hold the exception type and I don't want to copy over the server implementation assembly to the client.

In a nutshell:

ClientAssembly -> CommonAssembly, InterfaceAssembly
ServerAss开发者_运维技巧embly -> CommonAssembly, InterfaceAssembly

(in Common Assembly)

class MyException : Exception, ISerializable (this is implemented properly)
{ }

(in Server Assembly)

class MyServer
{
  public void MyFunc()
  {
    throw new MyException("custom message");
  }
} 

(in Client Assembly)

class MyClient
{
  public void MyFunc()
  {
     try { serverObject.MyFunc() } catch(MyException e) { // doesn't get caught. }
  }
}

It would be really helpful if there is a workaround for this. Also, if someone could shed light on why the assembly is required even when the type has been shared. Oddly, this issue doesn't occur if I use the System.Exception


I have solved the issue for once. On creating MyException, there was some data which was creating a problem during serialization. Still haven't been able to figure out what that would have been (since I was initializing with a simple string). However, i wrote a test app to try this and it worked with a simple exception. For now I have created a separate exception to deal with this. During it's serialization I make sure to not call base.GetObjectData. I am being able to catch it back in this case. My base.GetObjectData uses the FormatterServices to figure out the serializable fields and populate them. Some data inside that seems to be causing the problem.

Thanks for the help :)

0

精彩评论

暂无评论...
验证码 换一张
取 消