.NET Remoting 中的自定义异常传播失败,并出现 TargetInitationException 并显示“无法加载文件或程序集”

发布于 2024-09-27 02:20:23 字数 915 浏览 0 评论 0原文

我有一个使用 .NET Remoting 进行通信的客户端服务器应用程序。这是由接口分隔的,客户端不引用服务器的实现。现在,共享 dll 中的自定义异常在从服务器抛出时不会被客户端捕获,并且会抛出 TargetInitationException 并指出“无法加载文件或程序集 [服务器程序集]”。如果我将服务器程序集复制到客户端,问题就解决了。 考虑到服务器程序集甚至不保存异常类型并且我不想将服务器实现程序集复制到客户端,发生这种情况有点奇怪。

简而言之:(

ClientAssembly -> CommonAssembly, InterfaceAssembly
ServerAssembly -> CommonAssembly, InterfaceAssembly

在公共程序集中)

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

(在服务器程序集中)

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

(在客户端程序集中)

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

如果有解决方法,那将非常有帮助。另外,如果有人可以阐明为什么即使类型已共享也需要程序集。奇怪的是,如果我使用 System.Exception 就不会出现此问题

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
ServerAssembly -> 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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

辞别 2024-10-04 02:20:23

我已经解决了一次这个问题。在创建 MyException 时,有一些数据在序列化期间产生了问题。仍然无法弄清楚那会是什么(因为我是用一个简单的字符串初始化的)。但是,我编写了一个测试应用程序来尝试此操作,并且它只出现了一个简单的异常。现在我创建了一个单独的异常来处理这个问题。在序列化过程中,我确保不调用 base.GetObjectData。在这种情况下我能够把它抓回来。
我的 base.GetObjectData 使用 FormatterServices 来找出可序列化字段并填充它们。其中的一些数据似乎导致了问题。

感谢您的帮助:)

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 :)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文