使用 PostSharp 拦截对 Silverlight 对象的调用?

发布于 2024-07-04 15:49:19 字数 557 浏览 10 评论 0原文

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

所以,我向您提出的问题是..我缺少什么? 匹配属性目标下的方法调用似乎不起作用。

I'm working with PostSharp to intercept method calls to objects I don't own, but my aspect code doesn't appear to be getting called. The documentation seems pretty lax in the Silverlight area, so I'd appreciate any help you guys can offer :)

I have an attribute that looks like:

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

And an entry in my AssemblyInfo that looks like:

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

So, my question to you is... what am I missing? Method calls under matching attribute targets don't appear to function.

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

扫码二维码加入Web技术交流群

发布评论

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

评论(4

子栖 2024-07-11 15:49:19

我相信如果您将 AttributeTargetAssemblies 更改为“PresentationFramework”,它可能会起作用。 (PostSharp 还没有安装得那么好)。

WPF 的程序集是PresentationFramework.dll。 AttributeTargetAssemblies 需要它应该定位的 dll。

I believe if you change AttributeTargetAssemblies to "PresentationFramework", it might work. (Don't have PostSharp down that well yet).

The Assembly for WPF is PresentationFramework.dll. The AttributeTargetAssemblies needs the dll that it should target.

百善笑为先 2024-07-11 15:49:19

PostSharp 有一个新版本,可以从下载页面链接到“所有下载”进行访问。

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

该版本目前为 1.5 CTP 3,但支持 Silverlight。

PostSharp has a new version, which is accessed from the Downloads page link to "All Downloads".

PostSharp 1.5
The development branch of PostSharp including new features like support for Mono, Compact Framework or Silverlight, and aspect inheritance. Download from this branch if you want to try new features and help the community by testing new developments, and can accept inferior reliability and stability of APIes.

The version is currently at 1.5 CTP 3 but it has support for Silverlight.

∞梦里开花 2024-07-11 15:49:19

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

PostSharp 的工作原理是在 CLR 加载之前转换程序集。 现在,为了做到这一点,必须发生两件事:

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

最新版本 1.5 CTP 3 删除了这两个限制中的第一个< /a>,但真正的问题是第二个。 然而,这是一个强烈要求的功能,所以请密切关注去皮:

用户经常询问是否可以在运行时使用 PostSharp,因此不必在编译时了解各个方面。 部署后更改方面确实是一个很大的优势,因为它允许支持人员启用/禁用软件各个部分的跟踪或性能监控。 它能实现的最酷的事情之一就是在第三方程序集上应用方面。

如果你问这是否可能,简短的回答是肯定的! 不幸的是,长答案更加复杂。

运行时/第三方方面的陷阱

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

那么现在,有哪些陷阱?

  • 插入引导程序。如果您的代码被托管(例如在
    ASP.NET 或 COM 服务器中),您
    无法插入引导程序。 所以任何
    运行时编织技术势必
    您应该托管的限制
    自己申请。
  • 位于 CLR 之前。如果 CLR 自己找到未转换的程序集,
    它不会要求转换后的
    一。 所以你可能需要创建一个新的
    转换后的应用领域
    应用程序,并把转换后的
    其二进制路径中的程序集。 它是
    也许不是一个大问题。
  • 响亮的名字。哎呀。 如果在运行时修改程序集,则必须
    删除其强名称。 它会起作用吗?
    是的,大部分是。 当然,你必须
    从所有中删除强名称
    对此程序集的引用。 那是
    不是问题; PostSharp 支持它
    盒子外面。 但有件事
    PostSharp 无法提供帮助:如果有
    是一些强命名的引用
    字符串或文件(例如在
    app.config),我们很难找到它们
    并改造它们。 所以这里我们有一个
    真正的限制:不可能
    对强命名的“松散引用”
    大会:我们只能
    转换真实的参考文献。
  • LoadFrom。如果任何程序集使用 Assembly.LoadFrom、Assembly.LoadFile
    或 Assembly.LoadBytes,我们的
    引导程序被跳过。

This is not possible with the present version of PostSharp.

PostSharp works by transforming assemblies prior to being loaded by the CLR. Right now, in order to do that, two things have to happen:

  • The assembly must be about to be loaded into the CLR; you only get one shot, and you have to take it at this point.
  • After the transformation stage has finished, you can't make any additional modifications. That means you can't modify the assembly at runtime.

The newest version, 1.5 CTP 3, removes the first of these two limitations, but it is the second that's really the problem. This is, however, a heavily requested feature, so keep your eyes peeled:

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.

Runtime/third-party aspect gotchas

The author also proceeds to outline some of the problems that happen if you allow modification at runtime:

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.
你列表最软的妹 2024-07-11 15:49:19

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

If you're trying to intercept calls within the framework (i.e., not in your own code), it won't work. PostSharp can only replace code within your own assembly.
If you're trying to intercept calls you're making, then it looks like it should work. Do you see PostSharp running in the build output?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文