关于c＃：使用PostSharp拦截对Silverlight对象的调用？

Using PostSharp to intercept calls to Silverlight objects?

我正在与PostSharp一起拦截对我不拥有的对象的方法调用，但是我的方面代码似乎没有被调用。该文档在Silverlight领域似乎很松懈，因此，感谢您提供的任何帮助:)

我有一个看起来像的属性：

1
2
3
4
5
6
7

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

在我的AssemblyInfo中，条目类似于：

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

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

当前版本的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.