.NET Remoting 在 Web 应用程序中工作，但不能在 WCF 主机中工作

Posted 2023-04-12

【中文标题】.NET Remoting 在 Web 应用程序中工作，但不能在 WCF 主机中工作

【英文标题】：.NET Remoting works from a web app, but not from within a WCF host

【发布时间】：2014-07-16 23:57:36

【问题描述】：

这个问题让我困惑了几个小时，我完全没有想法。我有以下远程代码：

private static IRolesAndResourcesManager InternalConnect(string host, string operatorName)

    string url = string.Format("tcp://0:1/IProxyFactory", host, ServicePort);
    object o = Activator.GetObject(typeof (IProxyFactory), url);
    IProxyFactory factory = (IProxyFactory) o;

    return factory.CreateRolesAndResourcesManager(operatorName);

当从我们的网站中调用它时，它工作正常。但是，我们也从 WCF 托管服务（基本上是控制台应用程序）链接到同一个 DLL。当我从该进程中调用相同的方法时，我在以下行中得到一个异常：

return factory.CreateRolesAndResourcesManager(operatorName); // <-- Exception!

例外是：

System.InvalidCastException: 返回参数的类型无效。\r\n 在 System.Runtime.Remoting.Proxies.RealProxy.ValidateReturnArg（对象 arg, 类型 paramType)

到目前为止，我发现的所有内容都表明存在某种 DLL 不匹配；好像 WCF 进程链接到旧版本的 DLL。但是，我尝试删除每个二进制文件、清理、重建。哎呀，我曾经尝试过删除整个登记并再次从 Subversion 中检查所有内容。我还可以验证CreateRolesAndResourcesManager 方法在Remoting 主机端运行并返回有效数据。

除了 DLL 不匹配之外，还有什么其他因素会导致这种异常吗？有什么方法可以获取有关此错误的更多信息？

更新：

绝对不是 CLR 版本不匹配。所有三个进程（IIS Express、Remoting Host、WCF 进程）都有以下Environment.Version：

4.0.30319.18444
    Build: 30319
    Major: 4
    MajorRevision: 0
    Minor: 0
    MinorRevision: 18444
    Revision: 18444

我还以管理员身份运行了 Visual Studio 以及所有进程，以查看是否存在安全问题，但这也不能解决问题。

【问题讨论】：

Remoting 是一项遗留技术，保留它是为了与现有应用程序向后兼容，不建议用于新开发。现在应该使用 WCF 或 ASP.NET Web API 开发分布式应用程序。请参阅msdn.microsoft.com/en-us/library/vstudio/xws7132e.aspx 顶部的注释以获取证据。

@JohnSaunders - 同意。关于远程处理问题的每一个答案基本上都相当于“你为什么还在使用远程处理？”不幸的是，我们现在没有足够的带宽来更新我们的整个代码库。因此，我们暂时只能使用两者的混合体。

“我们现在没有足够的带宽来更新我们的整个代码库。” bandwith 是您打算使用的词吗？对于 BinaryFormatting 和 gzip 压缩之类的东西，如果带宽差异如此之大，我会感到惊讶。

我所说的带宽是指人类开发成本。转换我们所有的旧服务需要数周或数月的时间，但我们需要为下一个版本修复此错误。

CreateRolesAndResourcesManager 是否真的返回一个 IRolesAndResourcesManager？该错误表明该服务正在尝试返回一个未实现 IRolesAndResourcesManager 的对象。

【参考方案1】：

这个问题和答案：

System.InvalidCastException when creating a client activated object using an older version of an interface defined in a strong named assembly

建议如果服务器和客户端使用的.NET CLR 版本不同，可能会出现此错误，并且使用.NET Remoting 时，它们必须是相同版本的CLR。我不确定是否是这种情况，但你可能想检查一下......

【讨论】：

哦，我明天回到办公室时会检查一下！很好的假设！

@MikeChristensen - 我还看到有人提到，当包含程序集的 DLL 无法正确定位时，就会发生这种情况。显然，这有时会有些棘手。我猜你必须在连接的两边都有相同的组件。

与磁盘上完全相同的程序集？意思是，我不能“复制本地”？或者，只是逐个字节的同一个程序集？我在两个程序集上都运行了一个文件比较工具，它们之间的差异为零。另外，当我从网站调用它并且从 IIS bin 目录加载时它可以工作。

@MikeChristensen - 不，不是完全相同的组件。我的意思是两个副本。一般来说，这个错误似乎意味着由于某种原因无法加载程序集，或者因为强命名、冲突的 CLR 版本、具有相同定义的多个程序集、找不到程序集等等......它也可能与 CAS 相关...

@MikeChristensen - 您可以尝试启用程序集绑定日志记录并查找错误。 msdn.microsoft.com/en-us/library/e74a18c4%28v=vs.71%29.aspx 请注意，我曾经忘记关闭此功能，几个月后发现我的机器正在爬行...并发现数千兆字节的日志文件需要永远删除...