Mono 与 .NET 中可能的评估顺序不同答案

【问题标题】：Possible order of evaluation difference in Mono vs. .NETMono 与 .NET 中可能的评估顺序不同
【发布时间】：2013-03-07 23:17:39
【问题描述】：

我在一个对象上有一个 Equals 覆盖，以检查使用预编译的 protobuf-net 序列化器对象反序列化的两个对象之间的值相等性。我已经验证了反序列化按预期进行（在这方面，protobuf-net 很棒）。

这个类非常简单，但是其他更复杂的类也会出现类似的问题，所以我将使用它作为模型。

这里是有问题的代码片段：

public bool Equals (CompressionConfiguration other) {
    if (ReferenceEquals(null, other)) return false;
    if (ReferenceEquals(this, other)) return true;
return string.Equals (AlgorithmName, other.AlgorithmName) &&
        (AlgorithmConfiguration == null ? other.AlgorithmConfiguration == null : 
        AlgorithmConfiguration.SequenceEqual(other.AlgorithmConfiguration));
}

在 .NET 运行时执行时，这会按预期进行计算，从而允许 byte[] 类型的 AlgorithmConfiguration 为空值。在 Mono 下，我得到一个 SequenceEqual 空参数错误，特别是 ArgumentNullException。是什么赋予了？这不应该发生，因为只有在 AlgorithmConfiguration != null 时才应该调用 SequenceEqual。

这绝对是来源，因为如果我为 CompressionConfiguration 提供零长度字节 []，则不会发生故障。如果可能的话，我真的宁愿不发送零长度数组。我必须具有 Mono 兼容性，因为这将用于 Xamarin.Android (MonoDroid) 和 MonoTouch，以及 Mono 服务器，然后是 .NET 桌面应用程序。

【问题讨论】：

看起来 AlgorithmConfiguration 不为空，而 other.AlgorithmConfiguration 为空。这将通过您的所有检查。
这是同一个对象 - 并且 AlgorithmConfiguration 绝对为空。不过，这是一个很好的观点，谢谢！我将添加该案例。另外，我刚刚重新编译了序列化程序，现在它可以完美运行了。我很困惑。我没有改变任何东西......无论如何，它现在可以工作了。也许必须使用 Mono 编译器重新编译预编译的序列化程序才能在 Mono 下使用 - 我认为它使用的是在我的 Windows 机器上编译的 dll。反之亦然！
如果是同一个对象，“this”检查会捕获它
对不起，当我说相同时，我的意思是“具有价值平等”，而不是“具有相同的引用”

标签： mono protobuf-net

【解决方案1】：

奇怪的是，在 Mono 下重新编译序列化程序程序集解决了这个问题，即使这不是 ArgumentNullException 的来源，而且我已经验证了对象已正确反序列化。现在一切正常。

【讨论】：

这只是......奇怪！当您说“重新编译序列化程序程序集”时……具体是哪个程序集？我能做些什么来重现这个吗？
我有一个解决方案，我们称之为 MySolution。我有一个使用命名空间 MyProject.DTO 的项目，其中包含所有可序列化的数据对象。我正在使用 protobuf-net 的 precompile.exe 生成 MySolution.DTOSerialiser 类型的序列化程序集。 DTOSerializer 是我重新编译的。我没有重新编译 MySolution.DTO 项目或 MySolution.Tests。所有测试都可以在 Windows 下运行，但不能在带有 Mono 的 OS X 下运行。