c# - 使用 PostSharp 拦截对 Silverlight 对象的调用？

Question

我正在使用 PostSharp 拦截对不属于我的对象的方法调用，但我的方面代码似乎没有被调用。 Silverlight 区域的文档似乎很松散，所以我很感激你们能提供的任何帮助:)

我有一个如下所示的属性:

public class LogAttribute : OnMethodInvocationAspect
{
    public override void OnInvocation(MethodInvocationEventArgs eventArgs)
    {
        // Logging code goes here...
    }
}

我的 AssemblyInfo 中的条目如下所示:

[assembly: Log(AttributeTargetAssemblies = "System.Windows", AttributeTargetTypes = "System.Windows.Controls.*")]

那么，我想问你的问题是……我错过了什么？匹配属性目标下的方法调用似乎不起作用。

Answer 1

当前版本的 PostSharp 无法做到这一点。

PostSharp 通过在 CLR 加载之前转换程序集来工作。现在，为了做到这一点，必须发生两件事:

• 程序集必须即将加载到 CLR 中；你只有一次机会，你必须在此时接受它。
• 转换阶段完成后，您将无法进行任何其他修改。这意味着您无法在运行时修改程序集。

最新版本，1.5 CTP 3，removes the first of these two limitations ，但真正的问题是第二个。然而，这是 a heavily requested feature ，所以请擦亮眼睛:

Users often ask if it is possible to use PostSharp at runtime, so aspects don't have to be known at compile time. Changing aspects after deployment is indeed a great advantage, since it allow support staff to enable/disable tracing or performance monitoring for individual parts of the software. One of the cool things it would enable is to apply aspects on third-party assemblies.

If you ask whether it is possible, the short answer is yes! Unfortunately, the long answer is more complex.

运行时/第三方方面的问题

作者还概述了如果允许在运行时修改会发生的一些问题:

So now, what are the gotchas?

• Plugging the bootstrapper. If your code is hosted (for instance inASP.NET or in a COM server), youcannot plug the bootstrapper. So anyruntime weaving technology is bound tothe limitation that you should hostthe application yourself.
• Be Before the CLR. If the CLR finds the untransformed assembly by its own,it will not ask for the transformedone. So you may need to create a newapplication domain for the transformedapplication, and put transformedassemblies in its binary path. It'smaybe not a big problem.
• Strong names. Ough. If you modify an assembly at runtime, you will have toremove its strong name. Will it work?Yes, mostly. Of course, you have toremove the strong names from allreferences to this assembly. That'snot a problem; PostSharp supports itout-of-the-box. But there is somethingPostSharp cannot help with: if thereare some strongly named references instrings or files (for instance inapp.config), we can hardly find themand transform them. So here we have areal limitation: there cannot be"loose references" to strongly namedassemblies: we are only able totransform real references.
• LoadFrom. If any assembly uses Assembly.LoadFrom, Assembly.LoadFileor Assembly.LoadBytes, ourbootstrapper is skipped.