如何识别 C# 中给定方法中读取/写入的状态变量

Question

识别给定方法是否正在读取或写入成员变量或属性的最简单方法是什么？ 我正在编写一个工具来协助 RPC 系统，在该系统中访问远程对象的成本很高。能够检测给定对象是否未在方法中使用可以让我们避免序列化其状态。在源代码上执行此操作是完全合理的（但能够在编译代码上执行此操作将是令人惊奇的）

我想我可以编写自己的简单解析器，我可以尝试使用现有的 C# 解析器之一并使用 AST。我不确定是否可以使用反射对程序集执行此操作。还有其他方法吗？什么是最简单的？

编辑：感谢您的快速回复。让我提供更多信息以使问题更清楚。我绝对更喜欢正确的，但它绝对不应该非常复杂。我的意思是，我们不能走得太远，检查极端情况或不可能情况（正如前面提到的传入代表，这是一个很好的观点）。检测这些情况并假设所有内容都可以使用而不是在那里进行优化就足够了。我认为这些情况相对不常见。 我们的想法是将该工具交给我们团队之外的开发人员，他们不应该关心这种优化。该工具获取他们的代码并为我们自己的 RPC 协议生成代理。 （我们仅使用 protobuf-net 进行序列化，但不使用 wcf 或 .net 远程处理）。因此，我们使用的任何东西都必须是免费的，否则我们将无法部署该工具来解决许可问题。

Answer 1

您可以选择简单，也可以选择正确 - 您更喜欢哪一个？

最简单的方法是解析类和方法体。然后识别标记集，它们是类的属性和字段名称。方法主体中出现的这些标记的子集是您关心的属性和字段名称。

这种琐碎的分析当然是不正确的。如果您有

class C
{
    int Length;
    void M() { int x = "".Length; }
}

那么您会错误地得出 M 引用 C.Length 的结论。这是误报。

正确的方法是编写一个完整的 C# 编译器，并使用其语义分析器的输出来回答您的问题。这就是 IDE 实现“转到定义”等功能的方式。

Answer 2

在尝试自己编写这种逻辑之前，我会检查一下您是否可以利用 NDepend 来满足您的需求。

NDepend 是一个代码依赖性分析工具......等等。它实现了一个复杂的分析器来检查代码构造之间的关系，并且应该能够回答这个问题。如果我没记错的话，它还可以在源代码和 IL 上运行。

NDepend 公开了 CQL（代码查询语言），它允许您针对代码中结构之间的关系编写类似 SQL 的查询。 NDepend 对脚本有一定的支持，并且能够与您的构建过程集成。

Answer 3

要完成 LBushkin 对 NDepend 的回答（免责声明：我是该工具的开发人员之一），NDepend 确实可以在这方面为您提供帮助。下面的 代码 LINQ 查询 (CQLinq) 实际上匹配...

• 不应该 的方法引发任何 RPC 调用，但
• 正在读取/写入任何 RPC 类型的任何字段，
• 或者读取/写入任何 属性 >RPC类型，

注意我们首先如何定义4个集合：typesRPC、fieldsRPC、propertiesRPC、methodsThatShouldntUseRPC - 然后我们匹配违反规则的方法。当然，这个 CQLinq 规则需要进行调整以匹配您自己的 typesRPC 和 methodsThatShouldntUseRPC：

warnif count > 0

// First define what are types whose call are RDC
let typesRPC = Types.WithNameIn("MyRpcClass1", "MyRpcClass2")

// Define instance fields of RPC types
let fieldsRPC = typesRPC.ChildFields()
                .Where(f => !f.IsStatic).ToHashSet()

// Define instance properties getters and setters of RPC types
let propertiesRPC = typesRPC.ChildMethods()
                    .Where(m => !m.IsStatic && (m.IsPropertyGetter || m.IsPropertySetter))
                    .ToHashSet()


// Define methods that shouldn't provoke RPC calls
let methodsThatShouldntUseRPC = 
          Application.Methods.Where(m => m.NameLike("XYZ"))


// Filter method that should do any RPC call 
// but that is using any RPC fields (reading or writing) or properties
from m in methodsThatShouldntUseRPC.UsingAny(fieldsRPC).Union(
          methodsThatShouldntUseRPC.UsingAny(propertiesRPC))

let fieldsRPCUsed = m.FieldsUsed.Intersect(fieldsRPC )
let propertiesRPCUsed = m.MethodsCalled.Intersect(propertiesRPC)

select new { m, fieldsRPCUsed, propertiesRPCUsed  }

Answer 4

我的直觉是，检测哪些成员变量将被访问是错误的方法。我对实现此目的的第一个猜测是仅根据需要请求序列化对象（最好是在任何需要它们的函数开始时，而不是零散地）。请注意，如果这些请求连续快速发出并且很小，则 TCP/IP（即 Nagle 算法）应该将这些请求填充在一起

Answer 5

Eric 说得对：要做好这件事，您需要相当于编译器前端的东西。他没有充分强调的是对强大的流量分析能力的需求（或者愿意接受可能通过用户注释缓解的非常保守的答案）。也许他的意思是在“语义分析”一词中，尽管他的“转到定义”示例只需要符号表，而不是流分析。

普通的 C# 解析器只能用于获得非常保守的答案（例如，如果类 C 中的方法 A 包含标识符 X，则假设它读取类成员 em> X; 如果 A 不包含任何调用，那么您就知道它无法读取成员 X）。

除此之外的第一步是拥有编译器的符号表和类型信息（如果方法 A 直接引用类成员 X，则假设它读取成员 X；如果 A 不包含调用并提及< em>identifier X 仅在访问不属于此类类型的对象的上下文中，那么您就知道它无法读取成员 X）。您还必须担心合格的参考资料；如果 Q 与 C 兼容，QX 可以读取成员 X。

粘性点是调用，它可以隐藏任意操作。仅基于解析和符号表的分析可以确定，如果有调用，参数仅引用常量或不属于 A 可能表示的类（可能是继承的）的对象。

如果您发现一个具有 C 兼容类类型的参数，现在您必须确定该参数是否可以绑定到 this，需要控制和数据流分析：

   method A( ) {  Object q=this;
                     ...
                     ...q=that;...
                     ...
                     foo(q);
               }

foo 可能隐藏对 X 的访问。所以你需要两件事：流分析来确定对 q 的初始赋值是否可以到达调用 foo （它可能不会；q=that 可能主导对 foo 的所有调用），以及调用图分析来确定 foo 可能实际调用哪些方法，这样您就可以分析这些对成员 X 的访问。

您可以决定要走多远，只要您没有足够的信息来证明其他情况，只需做出保守的假设“A 读取 X”。这会给你一个“安全”的答案（如果不是“正确”或者我更愿意称之为“精确”）。

在可能有用的框架中，您可能会考虑 Mono，它肯定会解析和构建符号表。我不知道它为流程分析或调用图提取提供了哪些支持；我不希望 Mono-to-IL 前端编译器做很多这样的事情，因为人们通常将该机制隐藏在基于 JIT 的系统的 JIT 部分中。缺点是 Mono 可能落后于“现代 C#”曲线；上次我听说它只处理 C# 2.0，但我的信息可能已经过时了。

另一种选择是我们的 DMS 软件重新工程工具包 及其 C# 前端。
（不是开源产品）。

DMS 提供通用源代码解析、树构建/检查/分析、通用符号表支持和内置机制，用于实现控制流分析、数据流分析、指向分析（“对象 O 指向什么？”所需）。 ），并构建调用图。该机器已经通过 DMS 的 Java 和 C 前端的严格测试，并且符号表支持已用于实现完整的 C++ 名称和类型解析，因此非常有效。 （您不想低估建造所有这些机器所需的工作量；我们自 1995 年以来一直致力于 DMS）。

C# 前端提供完整的 C# 4.0 解析和完整的树构建。它目前不为 C# 构建符号表（我们正在研究这个），与 Mono 相比这是一个缺点。然而，有了这样的符号表，您就可以访问所有流分析机制（已经使用 DMS 的 Java 和 C 前端进行了测试），如果 Mono 不提供这些功能，那么这可能是 Mono 的一大进步。

如果你想做好这件事，你面前有大量的工作要做。如果您想坚持“简单”，则只需解析树即可，并且可以非常保守。

您没有说太多关于了解方法是否写入给成员的信息。如果您要按照您所描述的方式最小化流量，您需要区分“读”、“写”和“更新”情况，并在两个方向上优化消息。对于各种情况的分析显然非常相似。

最后，您可能会考虑直接处理 MSIL 以获取您需要的信息；您仍然会遇到流量分析和保守分析问题。您可能会发现以下技术论文很有趣；它描述了一个完全分布式的 Java 对象系统，它必须执行与您想做的相同的基本分析，
IIRC 通过分析类文件并进行大量字节代码重写来做到这一点。
Java Orchestra 系统

Answer 6

您所说的 RPC 是指 .NET Remoting 吗？还是DCOM？还是WCF？

所有这些都提供了通过接收器和其他结构监视跨进程通信和序列化的机会，但它们都是特定于平台的，因此您需要指定平台......

Answer 7

您可以使用类似于 INotifyPropertyChanged（尽管您显然不知道哪个方法影响了读/写。）

Answer 8

我认为你能做的最好的事情就是明确地维护一个脏标志。