C#：编写 MSIL 以添加预处理器指令

发布于 2024-08-19 08:52:01 字数 351 浏览 2 评论 0原文

是否可以在 C# 中编写 MSIL 代码，在满足特定条件时将预处理器指令添加到代码中，例如 #warning？或者也许这可以通过反思来完成，我不知道。

我正在尝试编写一个自定义属性，如果该属性错误地应用于类的方法或属性，则会生成编译器警告。使用现有的 Obsolete 属性将不起作用，因为仅使用我的自定义属性就会导致警告，而我不希望出现这种情况。我希望自定义属性构造函数检查条件，如果该条件为真，则会引发编译警告。

更新：读完我的问题后，我认为我所要求的是不可能的，因为我混合了编译时和运行时约束。我想我最终会执行构建后任务来检查刚刚构建的 DLL，并在条件成立时让它吐出错误消息。

原文

分享到QQ

分享到微博

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

发布评论

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

烟沫凡尘 2024-08-26 08:52:02

我从你之前的帖子中看到这个问题。错误地引用了伟大的杰米·扎文斯基（Jamie Zawinski）的话：“有些人在遇到问题时会想：“我知道，我会使用一个属性。”现在他们有两个问题”。

属性只是带外数据，被编译到程序集的元数据中。它不会影响程序执行或工具行为，除非程序或工具被明确编程为识别特定属性。它需要使用反射来做到这一点。

您需要做的就是编写自己的工具。它应该在构建程序集后执行，使用项目的构建后步骤。它需要加载程序集并使用反射来迭代程序集中的类型。对于每种类型，使用 Type.GetMethods() 迭代方法并使用 MethodInfo.GetCustomAttributes() 来发现和构造可能已编程的属性。

您可以使用 Type.GetInterfaces() 来发现该类型实现了哪些接口。现在，当您看到存在实现接口方法的方法但缺少这样的属性时，您可以抱怨。你的最终目标是：当你看到一个方法的属性表明它实现了一个接口方法，但该类型不再继承它时，你可以抱怨。

如果您发现任何令人反感的内容，请使用Environment.ExitCode 使该工具构建失败。这负责执行。顺便说一句：程序员真的讨厌破坏构建。这很可能会鼓励他们虔诚地使用该属性。或者它可能会鼓励他们编辑构建后步骤。

回复收藏 0 原文

梅倚清风 2024-08-26 08:52:02

编译器为自定义属性存储两件事：

要调用的属性构造函数要
传递给构造函数的每个参数的数据

仅当应用程序运行并且有人为您的 Assembyl、Type、MethodInfo、ParameterInfo 等调用 GetCustomAttributes 时，才会调用构造函数。

您还需要考虑一些其他选项：

编写一个自定义 MSBuild 任务，该任务在编译阶段之后运行，加载已编译的程序集并检查应用程序的属性使用情况。
使用 AttributeUsage 属性指定可以应用该属性的代码项。
将属性验证推迟到运行时。

回复收藏 0 原文

长梦不多时 2024-08-26 08:52:02

简而言之，不。预处理指令没有 IL 表示，因为它们仅作为源文件编译期间使用的元数据存在。

作为自定义 FxCop 规则，您正在做的事情可能会更好。

回复收藏 0 原文

懒猫 2024-08-26 08:52:02

您听说过 Boo 吗？它有一些有趣的方式可以连接到编译器管道。其中一项功能称为语法属性，它是实现编译器调用的接口的属性，以便它们可以参与代码生成。

class Person:
  [getter(FirstName)]
  _fname as string

  [getter(LastName)]
  _lname as string

  def constructor([required] fname, [required] lname):
    _fname = fname
    _lname = lname

此代码中的属性将为字段生成公共 getter，并为构造函数参数生成 null 检查。一切都将最终出现在编译后的程序集中。

我一直想要这种可扩展性成为 C# 编译器的一部分。也许有一天会的。在此之前，您可以使用后编译器，例如 CciSharp。 CCiSharp 将根据程序集中的特殊属性重写 CIL，就像 Boo 同步属性一样。

给定以下代码：

class Foo {
  [Lazy]
  public int Value { 
    get { return Environment.Ticks; } 
  }
}

CCiSharp 会将基于 LazyAttribute 的代码更改为：

class Foo {
  int Value$Value; // compiler generated
  int Value$Initialized;
  int GetValueUncached() { 
    return Environment.Ticks;
  }
  public int Value  {
    get {
      if(!this.Value$Initialized) {
        this.Value$Value = this.GetValueUncached();
        this.Value$Initialized = true;
      }
      return this.Value$Value;
    }
}

CCiSharp 基于通用编译器基础设施项目，同样用于实现代码契约即将推出的 .NET Framework 4.0 中的后期编译器。

这就是改变生成的 CIL 的方法。

但是，#warning 指令没有 CIL 表示，它只是编译器指令。要添加此指令，您必须改变的不是生成的 CIL，而是 C# 代码本身。您必须为此实现一个 C# 解析器。我认为最好的选择是，正如其他回复中所述，创建一个构建后事件，该事件将反映生成的程序集并发出所需的警告。

Have you ever heard of Boo? It has interesting ways in which you can hook up into the compiler pipeline. One such feature is called syntactic attributes, which are attributes that implement an interface that the compiler calls, so that they can participate in code generation.

class Person:
  [getter(FirstName)]
  _fname as string

  [getter(LastName)]
  _lname as string

  def constructor([required] fname, [required] lname):
    _fname = fname
    _lname = lname

The attributes in this code will generate public getters for the fields and null checks for the constructor parameters. It will all end up in the compiled assembly.

I've always wanted this kind of extensibility to be part of the C# compiler. Maybe it will one day. Until then, you can use a post-compiler, like CciSharp. CCiSharp will rewrite the CIL based on special attributes in the assembly, just like with Boo synctatic attributes.

Given this code:

class Foo {
  [Lazy]
  public int Value { 
    get { return Environment.Ticks; } 
  }
}

CCiSharp will mutate the code based on the LazyAttribute to this:

class Foo {
  int Value$Value; // compiler generated
  int Value$Initialized;
  int GetValueUncached() { 
    return Environment.Ticks;
  }
  public int Value  {
    get {
      if(!this.Value$Initialized) {
        this.Value$Value = this.GetValueUncached();
        this.Value$Initialized = true;
      }
      return this.Value$Value;
    }
}

CCiSharp is based on the Common Compiler Infrastructure project, the same used to implement the code contracts post compiler in the upcoming .NET Framework 4.0.

So this is how you can mutate the generated CIL.

But, a #warning directive does not have a CIL representation, it's a compiler directive only. To add this directive, what you must mutate is not the generated CIL, but the C# code itself. You'd have to implement a C# parser for that. I think the best option is, as stated in other responses, to create a post-build event that will reflect over the generated assembly and issue the desired warning.

回复收藏 0 原文