我正在与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.*")]

所以，我对问题是……我想念的是什么？匹配属性目标下的方法调用似乎不起作用。

解决方案

我相信，如果将AttributeTargetAssemblies更改为" PresentationFramework"，它可能会起作用。 (还没有把PostSharp压倒这么好)。

WPF的程序集是PresentationFramework.dll。 AttributeTargetAssemblies需要它应针对的dll。

如果我们试图拦截框架内的调用(即不在我们自己的代码中)，它将无法正常工作。 PostSharp只能替换我们自己程序集中的代码。
如果我们尝试拦截正在拨打的电话，则看起来应该可以正常工作。我们是否在构建输出中看到PostSharp运行？

PostSharp有一个新版本，可从"下载"页面链接到"所有下载"。

PostSharp 1.5
PostSharp的开发分支包括新功能，例如对Mono，Compact Framework或者Silverlight的支持以及方面继承。如果我们想尝试新功能并通过测试新开发来帮助社区，并且可以接受API的低可靠性和稳定性，请从此分支下载。

该版本当前为1.5 CTP 3，但支持Silverlight。

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

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

• 程序集必须将要加载到CLR中。我们只会得到一枪，此时我们必须采取行动。
• 转换阶段完成后，我们将无法进行任何其他修改。这意味着我们不能在运行时修改程序集。

最新版本1.5 CTP 3消除了这两个限制中的第一个限制，但实际上是第二个限制。但是，这是一个非常需要的功能，因此请睁大眼睛：

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 in
  ASP.NET or in a COM server), you
  cannot plug the bootstrapper. So any
  runtime weaving technology is bound to
  the limitation that you should host
  the application yourself.
  Be Before the CLR. If the CLR finds the untransformed assembly by its own,
  it will not ask for the transformed
  one. So you may need to create a new
  application domain for the transformed
  application, and put transformed
  assemblies in its binary path. It's
  maybe not a big problem.
  Strong names. Ough. If you modify an assembly at runtime, you will have to
  remove its strong name. Will it work?
  Yes, mostly. Of course, you have to
  remove the strong names from all
  references to this assembly. That's
  not a problem; PostSharp supports it
  out-of-the-box. But there is something
  PostSharp cannot help with: if there
  are some strongly named references in
  strings or files (for instance in
  app.config), we can hardly find them
  and transform them. So here we have a
  real limitation: there cannot be
  "loose references" to strongly named
  assemblies: we are only able to
  transform real references.
  LoadFrom. If any assembly uses Assembly.LoadFrom, Assembly.LoadFile
  or Assembly.LoadBytes, our
  bootstrapper is skipped.